How Engineering Team Organization Helps to Build Compatible System Architecture
By Hannah Riley November 26, 2018 10 mins read
An engineering team’s organizational structure is an essential element of their success and growth. After chatting with Bill Salak, the Senior Vice President of Technology at ABC Mouse, on our podcast, Tech People, it got me thinking about how deep this organization goes. Team organization can easily go unnoticed in the daily pursuit of individual tasks, but should never be taken for granted. Putting thought and intention into your organizational methods, and having a solid foundation set in place is the key to the success for any engineering team.
Management Style and Practice
When managing an engineering team, there are many factors to consider. At the foundation of the standards we have built at Gistia, we prioritize cohesive communication. And I don’t just mean our team needs to communicate well; it goes beyond this. In order for our clients’ product to be as good as our clients need them to be, we need to synchronize our team with our clients’ project goals.
Take these two examples into consideration:
Team A is working on a project. They review the project individually in an email sent to them by their team leader and begin to tackle the project individually. The work they produce is good, but now two team members have built conflicting components. They have interpreted the goal of the project differently, and are now forced to backtrack and rebuild the product. Poor communication and team structure have lead Team A to build a product that is incompatible with their client’s needs.
Team B reviews a new project together. They create a plan and delegate necessary components. They meet weekly to make sure everyone is on track with the timeline, hashing out issues they run into and fixing bugs. As the project moves along, they make sure the product is easy to use and cost effective for their client. Team B has created a smooth system of communication amongst its team members and it shows in their product outcome.
To put this concept into perspective, I’d like to bring up a reference to Conway’s Law. During my interview with Bill Salak, he summarized his perspective as “A company will design a system that is a copy of the organization’s communication structure. Effectively, the way you organize your company will impact the way your products are designed.” In other words, having clear communication sets you up for success. We create a body of work that’s efficient and effective by modeling our products as we do our own team. Think about it— if you have a team putting together various pieces of a project, and everyone involved is tackling the project based on their own individual standards, you’re going to end up with a mess.
Skill Development vs. Length of Employment
When building and growing an engineering team, there are many things to consider. Sure, the obvious answer is to hire the most experienced person for the job, but is that really the best thing to do? If you hire only the most experienced people, you could inadvertently create an environment where team members are expressing conflicting views with stubbornness of who is more right. And beyond this, you are going to find employees who are uninspired to grow because they are already at their peak.
At Gistia, we believe in setting up an environment driven by employee development. What this means is that we set our employees up so that they are encouraged to learn from one another. When you implement mentorship into your team’s organization, you build a culture that chooses collaboration over competition. Think about it— if you hire someone new who has the basics down and can get things rolling, when they run into an issue they can easily seek mentorship from a more senior team member. The senior team member is satisfied because they have been helpful, and they are passing along this knowledge. It gives them a greater purpose to see someone excited and eager to grow. The junior team member gets to learn about the areas they are interested in and seek growth in. In this way, the team members are working together.
What happens when a team member wants to move up in the company? Simple. Building a model where people want to grow allows them to move at different paces. Imagine, you have one very eager team member putting in extra hours, who is inspired by the learning possibilities your company has to offer. They are going to move up at a much faster pace than someone who is a little slower and methodical in their approach. Many businesses choose to promote their teams based on how long they have been employed. This model works fine for them; but if you hire people who have shown their enthusiasm within the company and continue to move up by gaining the knowledge they need to advance, you’re creating an environment that encourages people to want to learn and grow, and you’re rewarding them for growing.
Seniority should be built on a methodology of growth that allows people to earn their seniority through hard work and skill development, rather than basing growth off how long someone has been with a company.
How Hierarchy Helps Engineering Teams
It may not seem obvious at first, but when you arrange your team successfully, the effects ripple into the work produced. We have gone over company growth and how important the clarity of communication is amongst team members. Now imagine this continuing into project portfolios.
As engineers, success is not just creating the most complex code. Engineering firms have very smart people working for them; their ability to create complex code is not in question. But even the most complex coding is not successful in the long run if those skills are not transferable to your junior engineers. If your code is only able to proceed one generation of engineers, you become dependent on your senior team members. New employees have to play catch up, which creates more work for everyone, and does not last long term. This knowledge transfer is a succession that can be used in your favor. Within a growing company like our own, we need to be able to elevate strong people quickly and replace their role in the project after elevating them. For this to work, system architecture needs to be simplified and standardized to allow junior engineers to provide value. Otherwise, only senior engineers can participate.
When building any new system you should be thinking of keeping a balance between two factors:
- Creating a system architecture that’s usable and repeatable in the long run.
- Creating code that’s not too complex so that the code is sustainable.
If you accomplish these two goals you will have made your team’s time worthwhile, because this code will be standardized and repeatable.
Why Should You Care?
Team organization is fundamental to building compatible system architecture. They go hand in hand. Starting with a foundation built on communication encourages a business practice where team members not only want to grow but are clear on how to grow. The work produced is more efficient when your team members are working together and seeking mentorship to solve problems, instead of competing against one another. In the same way, seniority is found more valuable and employees retention is increased when it’s earned through growing.
You may feel like you’re sacrificing the quick production of expert coding, but when you hire someone with less experience and wait for them to grow, the team moral you build will take your engineering team farther in the long run. These practices have proven their worth in the value of the products we at Gistia produce for our clients. We create code that is usable, not too complex and develop lasting relationships with our clients based on these proven methods.