On Being a Communicator on an Engineering Team

I'm on a new team at work temporarily and I this was something that I was so excited about.

I've never had an opportunity to work on a larger team with so many different experts.

The biggest thing I'm noticing with this new assignment is that while everyone has their expertise, constant communication has been the most important trait for all us as Software Engineers, SREs, Security Specialist, Architect, and yes DevRel Specialist are some of the less important factors.

Written communication

I'm not talking about your ability to speak corporate or create a solid email. I'm talking about the skills that are needed to draft a proposal to convince your team (and often decision makers) to run with an idea.

Documentation is important, including in the decision making process

Imagine having to create an issue for creating an issue. This is actually what I would love to see happen with all of my projects. Our team has a large list of decisions that need to be decided on. We then create a proposal for it and allow for the rest of the team to give their feedback.

Once we have a great concept of whether or not this thing should be worked on and to what effect, a new write-up is then entered into the decision record. Sometimes your proposal will vary greatly from the decision record entry.

A completely true story:

I was assigned the design, documentation, and development of our user API. This started with the proposal of the development of the API. This was quickly discusses and approved and I began creating the diagram for the User API with all the information that knew. There were plenty of decisions that hadn't been made yet, like auth, and validation, and even what API framework would be used.

Two days into work and what I had was an amazing diagram, one decision record about how the API would be developed (no specifics) and about 5 more proposals for myself and others to make a bunch of decisions on.

Then I jumped into some of the first endpoints and repeated the process. I have yet to write a single line of code on this.

Old me would have had an API built already and it would have not taken into consideration many of the decisions that have yet be decided. While my old method increases the number of commits that need to be made, it reduces the number of them that have to say "[FIX]...".

No one works alone

Our team made a very early decision that no one works alone. That means simply put, no one is allowed to implement things because THEY thought it was the right thing to do and no one cosigned.

That means that we are in almost constant communication and it's so important that when there is an agreement (or disagreement) people are eager to communicate their thoughts and ideas quickly as to not hinder production. The best part about this is that high-pace means you iterate quickly purely out of needing to.