DON BOSCO TECHNICAL COLLEGE

ASSIGNMENT IN FINIT


Submitted by:
John Paul Bautista
4-IT-A

Submitted to:
Ms. Ma. Luisa Padlan





























By Implication is an independent gaming and software development firm that is
based in the Philippines. They have won the 2010 Microsoft Imagine Cup Game Design
Competition and their applications such as sakay.ph and Sari Software have been
featured on some news outlets such as TV and News Articles. Ive caught up with their
project manager, Mr. Kenneth Yu who Ive communicated with through E-Mail. He was
kind enough to answer some questions regarding their organizational style and how
they come up with their innovations and products.

1. What is the organization's Mission/Vision?

We make cool stuff. Games, mobile apps, websites and programs are all on the
table. We want to continue making these in the future, all the while improving the
general quality and skill of creative IT work in the Philippines.


2. Discuss how the firm is organized.

We try to be as flat a firm as possible; the common joke is that we're
"communists." So, no permanent hierarchies. Everyone, from the initial founders to the
newest recruits get equal pay and equal say in the company's direction.

We do, however, break into clusters or groups as necessary. (This usually
becomes the case when we're working on a particularly complex project, with a lot of
individual segments that need to be built.) Each of these clusters has one or two team
leaders, who is accountable for the progress of the project in general. Once the project
is done, however, the cluster dissolves, and we return to a no-hierarchy setup.
There are also occasional clusters that are form for the purpose of teaching,
instead of expressly completing a project. In this case, you have (again) one or two
people assigned to provide knowledge as the mentor, while all other members of the
cluster are students, who are meant to learn as much as they can.


3. What is your leadership style?

I base my leadership style on the hierarchy of the company. As the manager, I'm
acutely aware that I'm really the dumbest person in the room. Everyone else has the
ability to create products, programs, art and assets directly. My only true role is to get as
much anxiety, deadline process and administrative difficulty out of their way, so they
can do the awesome work they want to do.

So! When it comes to strategy, I must count myself as a single voice out of many.
I have my ideas for how the company should act, but in general, I obey the demands of
the popular vote.

The majority of my true managerial / leadership work boils down to clarifying the
company's options when dealing with situations, deciding the correct time to call for
votes and meetings, and providing the input of someone with management training
when decisions become unclear or difficult.



4. Comment on the process control in your organization.

One thing that I only learned about programming and IT product / service
development when I started working in the field is that it's not as mechanical, or even as
controllable as people expect.

Many business managers have the tendency to think of programming as a very
sterile, mechanical process. They see programmers as the people who have to build a
house, based on an existing product spec sheet.

The reality is that programmers are much closer to architects and engineers than
anything else. While an existing spec sheet helps the process along, a programmer
must still make a lot of high-level decisions on their own.

Because a lot of these high-level decisions force them to choose between (or
actually create) multiple solutions which all have the potential to solve the problem (and
all incur varying penalties to efficiency and program quality), programmers also takes on
qualities of artists and strategists. There is a great deal of creativity involved in
becoming a real programmer.

With all that said, process control within the company is more an issue of talking
to and motivating individual people than of carefully micro-managing, designing and
controlling a mechanical system.

With deadlines or any other important parameters, programmers themselves
need to be consulted as often as (or even more often than) the clients / shareholders /
project leads. This is because only the programmer can provide final input on how long
a particular task will take, especially if the task is a complex one. (Many companies
favor imposing deadlines without any input from programmers, but this leads very often
to stressed employees, missed deadlines and rushed work. Because we are a small
company, we cannot afford this.)

It's possible, of course, that some employees may need some help keeping up
with deadlines. This is where I come in. Another part of my job is checking in with
programmers, designers and artists every so often, to see how much progress they've
made towards their deadlines, and how much additional help they need if they think
they're falling behind or encountering problems.


5. Evaluate the innovative material process.

Honestly, I'm still not quite sure what you mean by this one. I'm just going to
guess at it, and assume that you're asking about how we come up with ideas for work.

When it comes to games, we're usually inspired either by things we enjoy (certain
genres of games, certain sci-fi, fantasy or horror stories), or by a funny joke that we end
up talking about over and over again ("Okay, what if there's this kid, and he trolls people
by constantly running up an escalator that's going down? What if we turn that into an
endless runner game?")

When it comes to apps, the process is usually a lot clearer. By chance or by
analysis, we tend to notice areas that people need help in. We will, for example, notice
that local comic book creators have a hard time printing and distributing their work.
Based on this, we'll come up with an idea for an app that might help solve the problem,
and begin doing research into what a user would actually want or need out of such a
product.