ENGINEERING TEAM: HOW TO BUILD AND MANAGE THE BEST TEAM?

When you’re running a software engineering team, and someone tells you that good engineering management doesn’t exist, it can be more than a little frustrating. In fact, to manage an engineering team in an ambitious, fast-paced startup requires a unique blend of technical leadership, engineering management, project management, and people management.

I know how challenging it can be to lead a group of autonomous engineers—or any group of employees. So this article will help you find out how best to run an effective engineering team.

Making a good Engineering Team Culture

I have distilled 7 things that a team can do to build a good engineering team culture:

Push relentlessly toward automation

Solution automation and repetitive task scripts are important as they free up the engineering team to work on the actual product. Ensuring that services are automatically restarted whenever possible when they fail and that services are replicated easily and quickly during traffic spikes is the only sensible way to deal with the complexity on a large scale. In the short term, there is always the tempting compromise of applying a tape – helping quickly manually instead of automating and testing a long-term solution.

Create the right software abstractions

Maintaining simple and common abstractions reduces the need for custom solutions and increases the team’s familiarity and experience with common abstractions. The increasing popularity and reliability of systems like Memcached, Redis, MongoDB, etc., have reduced the need to create custom caching and storage.

The team’s focus on a few core abstractions rather than fragmenting it into many ad hoc solutions means popular libraries are becoming more robust, monitoring becomes smarter, performance characteristics are better understood, and testing becomes more complete. Contribute to a simpler system with a reduced operational load.

Focus on high code quality with code reviews

Maintaining a high-quality codebase increases the productivity of the entire engineering team. Cleaner code is easier to understand, faster to develop, faster to change, and less prone to errors.

A healthy code review process makes this possible. Having timely code reviews, either before or after commit, improves code quality in several ways. First, the peer pressure of knowing that someone is reviewing your code and committing poorly written code will likely disappoint your teammates—hacky code, not maintainable or untested. Second, code reviews provide opportunities for the reviewer and code writer to learn from each other to write better code.

If code reviews are easily accessible to other members of the engineering team, reviews also have the benefits of

• Increasing responsibility for timely review of the code
• Enabling team members, especially the newer ones, to write good code to model reviews from others
• Accelerate the spread of coding best practices

Build shared ownership of code

While it is natural for humans to become familiar with different parts of the codebase or infrastructure, no one should feel like they own an individual part or are solely responsible for it. Could increase the effectiveness in the short term, this approach is detrimental in the long term.

Many engineering organizations make it too early by breaking the entire team into sub-teams with technology leaders when the team is still small.

Maintain a respectful work environment

Peer-to-peer respect forms the basis of all open communication. A place where people feel comfortable questioning the ideas of others is a place where strong ideas are forged through discussion. A place where people are easily offended is a place where important comments are withheld.

Create a learning and continuous improvement culture

A corollary to building a learning culture is to focus on mentoring and training to ensure everyone has the basic algorithms, systems, and product knowledge needed to succeed. Recruiting more effort has to be invested in mentoring and training. It may be a burden for a single mentor to spend an hour a day on a new employee’s job for the first 4 weeks, but this investment makes up less than 1% of the time The sum that the new employee goes through in a year and has a significant impact on whether the person is set for success.

Hire the best developers

Hiring the best is the foundation of many of the other philosophies listed. It’s hard to respect someone when you think they’re a B-level engineer. It’s hard to empower someone in product development if you don’t trust your product instinct. Recognize the right abstraction to build without sufficient engineering experience. It’s easy to fall into the trap of building something complex without other smart people questioning your ideas and leading you to simplicity.

Building a good engineering team culture needs a lot of work. But the resulting work environment is worth it.

Making Your Engineering Team More Effective

As a leader, you have an incredible opportunity to make a difference as your decisions directly affect the outcome of your entire team. The good news is there are also many tips to help you motivate your engineering team.

Gather input as to what’s hard or frustrating

As a seasoned person on the team, you have likely acquired a great deal of knowledge about working effectively. Still, that knowledge may also have left you impervious to the weaknesses that may exist for others.

The development workflow is based on putting together many undocumented tools that need to be used in a certain way, or you may quickly navigate the codebase or internal tools. Still, others lack the same mind map of where things are. Or you know which key stakeholders need to be consulted and when for a project, but it’s not obvious to everyone else on the team. Your team would be much more effective if you could fill in those gaps.

To find out what the gaps are, you first need to collect data. In one-to-one meetings, you can learn informally what works and what doesn’t. Or, if you want a more systematic approach, you can also do a technical survey as we did recently. You conduct an anonymous survey of ~ 30 minutes. In general, it’s going very well!

But we also learned about certain tools and pieces of the code base that people feared and some difficult things that people thought should be easy. These insights have led to subsequent discussions and initiatives on how we can improve things.

Align someone’s growth goals with what creates value

Have an explicit conversation with your engineering team members about where they want to grow and how you can become an ally to support that growth. Professional growth is best left to managers.

This limiting belief results in a missed opportunity. When a person’s career goals and dreams align with what they are doing, they will be more energetic and enthusiastic and produce higher quality work. Find creative ways to support your goals and create business value?

Maybe someone would like to improve their speaking skills in public – what opportunities to speak could you create to increase knowledge sharing and improve your communication skills? Or maybe someone with more technical responsibilities would like to be challenged – what could you delegate to free up your time to focus on higher leverage activities? Or maybe someone wants to understand the business better – how can you facilitate these conversations and use new insights to shape your product roadmap better?

Suppose we’re open to it, often creative ways to find a match between what people want and what the company or team wants. To unlock that value, start with an explicit conversation about what everyone wants.

Frequently give and request honest feedback

Do your engineering team members know how they’re doing? Sometimes we refrain from giving feedback because we assume it is obvious or the recipient is uncomfortable with it. Know what they are doing well and where to improve?

If the feedback comes from a good intention (e.g., you want this person to be successful) and if you explicitly share that intention (e.g., “I want to help you succeed in your role”), frame the intention of the feedback is much more likely to be appreciated and appreciated.

Arrange one-on-one meetings with the employees of your team and exchange feedback:

• What would you like the person to do more? Fewer?
• What do you think is possible for this person?
• What are your assumptions about each other?

Leverage your strengths to level up the team

What are the strengths that make you an effective engineer or engineering team leader? How can you use these strengths to give the engineers on your team a competitive advantage in their work?

For example, if you have extensive systems experience, how can you ensure that your building systems meet your goals? If you have a keen sense of the product, what feedback could you give on ongoing projects to increase the likelihood of success? If you consider yourself a productivity guru, what tools might exist, or could you guide the team in building them to make everyone more effective?

Personally, I have developed a passion and skills for coaching and leadership development. I wonder how I could raise the bar on technical leadership, and I focus a lot of my energy on training engineers to achieve what they want to teach leadership. Ability to moderate group discussions and, in general, recognize development opportunities in a particular task, project, or situation.

Reduce sources of complexity

Complexity is the enemy of execution. It has many hidden costs that engineers ignore, and it is becoming an ever-increasing drain on our spiritual energy and time. Actively fight against it.

In a conversation the other day, some people on my team discovered that the number of commits we’ve made over the past few years had not grown as fast as our team. Our engineering team has more than doubled since I joined, but we’ve nowhere near doubled the number of confirmations. “Commits aren’t a big measure of productivity – we close bigger deals, work on bigger projects, and develop better tools so we can use fewer code changes to get things done.

One of the main reasons the engagement rate slows down, however, is complexity. New engineers need to improve more code, more systems that need to be maintained and scaled, more interface and context in the product for integrating new projects, and more employees need to be coordinated for things to happen. So anything we can do to reduce code complexity, system complexity, product complexity, and organizational complexity will pay off as the team continues to scale.

Create more opportunities for collaboration

Because we want to do so much, we tend to split tasks and then have them processed individually because it is more efficient. The downside is that a person’s projects can make the work less motivating. Your normal workflow can be an effective way to increase motivation and enthusiasm.

Certainly, you can do many things to make your engineering team more effective. These ideas are just a starting point. Experiment and see what works well, then copy the strategies that you think will have the most impact on your team.