Article development led by
When people don’t work well together
they make bad decisions.
BY KATE MATSUDAIRA
IT ALL STARTED with a bug.
Customers were complaining their information
was out of date on the website. They would make an
update and for some reason their changes were not
being reflected. Caching seemed like the obvious
problem, but once we started diving into the details,
we realized it was a much bigger issue.
What we discovered was the back-end team managing
the APIs and data didn’t see eye-to-eye with the front-
end team consuming the data. The back-end team
designed the APIs the way they thought the data should
be queried—one that was optimized for the way they
had designed the schema. The challenge was that when
the front-end team wrote the interface, the API seemed
clunky to them—there were too many parameters, and
they had to make too many calls. This negatively
impacted the mobile experience where
browsers can’t handle as many concur-
rent requests, so the front-end team
made the decision to cache part of the
The crux of the issue was the teams
had not communicated well with each
other. Neither team had taken the time
to understand the needs of the other
team. The result was a weird caching
bug that affected the end user.
You might be thinking this could
never happen on your team, but the
reality is that when many different
people are working on a problem,
each could have a different idea about
the best solution. And when you don’t
have a team that works well together,
it can hurt your software design, along
with its maintainability, scalability,
Most software systems consist of
parts and pieces that come together
to perform a larger function. Those
parts and pieces can be thought out
and planned, and work together in
a beautiful orchestra. Or they can be
designed by individuals, each one as
unique as the person who created it.
The challenge is if you want your software to last, uniformity and predictability are good things—unique snowflakes are not.
One of the challenges of managing a software team is balancing the
knowledge levels across your staff. In
an ideal world, every employee would
know enough to do his or her job well,
but the truth is in larger software
teams there is always someone getting up to speed on something: a new
technology, a way of building software, or even the way your systems
work. When someone doesn’t know
something well enough to do a great
job, there is a knowledge gap, and this
is pretty common.
When building software and moving
fast, people don’t always have enough
time to learn everything they need to
bridge their gaps. So each person will
make assumptions or concessions that
can impact the effectiveness of any software that individual works on.
Is a People