The DNA of a great dev team

TL;DR Yes, we’re all looking to recruit and work with a great team. But you can’t get an exceptional or even a mediocre product without great team communications.

Really? But each team member is busting his a** on the product, and working day & night (mostly nights) to ship on time! How can it be that we won’t make it?

‍

The Team

When working in a team (that’s the “we” part), each member has a role. Ideally there would be front-end and back-end developers which need to communicate to each other, to the product manager / owner, to team leaders etc. So, they actually need some sort of a “human API” between them.

But, you say, my team members all sit together in the same open space and we’re in constant communication and conversations and meetings all day long!

Yes, they talk, but do they clearly exchange the bits of data that are critical to their jobs?

‍

The Product

Traditionally, your product would require at least one API, which serves as a formal contract between stakeholders, where the rules of communication and expected input / output are clearly defined and well known by all sides involved.

How would you go about designing and building an API for your product? You usually define a scope, data paths, server functional requirements and functions / API endpoints. You design a database and connect your server to the database to get & persist data. That means you know all the bits and bytes and the flow of data is well defined.

With this information specified and laid out in a clear way, the client and the server can communicate and respond to user requests with the relevant data being returned.

Sure it takes work, but remember that once the foundations are in place, we can make hundreds of calls per second, or x1000 that number if the server is built to scale.

Because the infrastructure is there and the rules are defined.

So you say, that’s how the product works, Great. How does that relate to building the product?

Well, it’s exactly the same.

‍

Talk is cheap

The developers, designers, PMs and everybody else can be precieved as endpoints talking to each other. They have to get user input — it can be a PRD / designs on Zeplin / Swagger specified APIs etc. — process it and come up with a result — their specific part / flow of the product.

In order to do that, however, they have to communicate to each other. You know, talking, Slacking, Skyping or whatever.

The problem is that as much as verbal / written free-form communication is important, it tends to become very exhausting and frustrating in nature.

For comparison, imagine that when the client is about to contact the server with some data in order to get a response, it would first ask the server:

What type of data are you expecting to get?

Is this the same type of data you were expecting before or is there a change?

How should I structure the payload?

Which endpoint should I contact for this request?

… etc.

Regardless of the super-fast systems we have in place today, asking all those questions will slow things down so much that client-server communication would take allllllllot of time.

Now, what would happen, if on top of the above questions, the server wouldn’t have the knowledge to respond to the client with clear answers?

So instead it would reply with:

• What type of data are you expecting to get?
  “Hmm, not sure, what did you send last time?”
• Is this the same type of data you were expecting before or is there a change?
  “There is some change for sure, but it’s not yet documented. Let’s set a time for a meeting to discuss this and figure it out. I also might introduce some additional changes by the time we meet. So best is to hold on this for now.”
• How should I structure the payload?
  “Well, usually we go with model structures, but as this is just a simple call maybe you should just send the data as-is. Whatever is easier for you. Let’s just be clear & consistent about it, shall we?”
• Which endpoint should I contact for this request?
  “If it’s for model A, go through endpoint “A”. Otherwise go through “B”. But if it’s for models D to F, go through endpoint C, because those models have been added later and haven’t been taken to account originally.
  Don’t worry, It’ll all be refactored later in the project.”

How fast do you think such an app will run and how will it respond to user actions? How well will it perform with so much time going in between each call? And what feedbackwill the user get, without being able to precisely process the responses the app gets?

And what would be the efficiency of your TEAM when working in this manner?

When we don’t define clear rules about our team product-relatedcommunications, our inter-team policies and our expected day to day results, we lose ourselves fast in the sea of design changes, business rules, pixel density and API versions, all communicated in whatever way way most convenient at that moment.

It’s not just a matter of being productive or not, but a matter of getting it done at all. No matter how much time is spent and how many developers are being recruited, without formal ways to communicate and without standard define-design-implement-review processes, no project can be completed on time, in budget and in high quality.

And that’s what we’re actually looking for as developers, team leaders and product owners, aren’t we?