My Thought about Building Solid and Great Software Engineering Team
Building Software Engineer Team is like planting a plant. If you want that plant's long life. You need to take care carefully.
“Home is where your plant’s live”
A half-decade ago, I’m starting my IT Company, with my position as an Owner will give me full control of my team. But running a business is not that easy. We went bankrupt. And in 2019, I'm starting my career again in a Tech company as an Engineering Manager. Right now I’m facing a different problem, previously I have full control of my team. But right now, I don’t have any full control of my team.
For the last 5 years until now, The only common problem that I face is PEOPLE COME AND GO. If we as a leader think that you already trying to build a solid team with the way that you belief but still your team just come and resign 6 or 1 years later. You might change your mindset.
Building a strong team is both possible and remarkably simple. But it is painfully difficult
As a company, building a great software engineering team is not only how you can give six figures salary. And as a leader, building a great software engineering team is not only how master you are and it’s not only about how fancy technology stack you are using. It’s more than that. It’s a combination between Business, Technology, and Morale.
See The Lencioni Method below
That pyramid demonstrates the components of a strong team. Before you focus on results and business purposes, you need to build trust between your team, then develop your people so that they more Agile and Mastering on any problem that might they face. This is the basic framework you need to inject into your team DNA. But in software Engineering team slightly different. Before you focus on those points Building Trust, Mastering Conflict, and so on you need to build a basic Framework for your software engineering team.
I create simple graphics based on my method. This is just the method that I create based on my experience. I modified The Lencioni Method without losing an existing key.
To build a great software engineering team, you need to start from the bottom first. Otherwise you will have a dysfunctional team.
Build Team Framework is the First step
I know, in your company, you have a very tight timeline. The C-Level got pushed by the investors to release MVP product within the next month. Do you know that the culture you built from the beginning will be always there until the project ends, But you realized that your project will never end? You already bringing your team until this far. Unclear vision, Lack of Documentation because you start in a rush, No KPI, Bug coming every second, and afterwhile you got a message from one of your team “Hi Mr, are you free tomorrow? I have some discussion about me. Thanks”
Something strange right? you know it will become a disaster. One by one your team resigns. Hiring and replace technical team is not an easy task. Let them go is not a good solution.
The rice has become porridge
Before we going to Product and Business Purpose ( Result ) We need to build a great team framework first. How you will bring your team on the same track? whereas you don’t have any good framework for your team.
What Culture and Project Management do you want to adopt ?
On this day you will see so many cultures adopting that impact into SDLC Process. Will you adopt the Waterfall ? or maybe you will adapt Agile and Scrum culture? You need to make it clear. Once you decide, make sure your team is ready for that. If you put your team on Agile Culture you need to inject the agile DNA into your team. How you and your team will break down the and deliver task, how your QA’s will test and escalate bug. Define together what *TASK DONE* means. Switching the development method is not easy, doing an experiment is like bringing your team into the abyss. It’s fun for you, but a disaster for your team productivity.
Build Product Oriented Team
Product Oriented Team will bring you to the next level. Product-oriented engineering teams do more than just write code. They’re more than just a feature factory; they’re co-owners of the product experience. I always saying this to my team “A great engineers, do not just come to the office and finishing their task. But also giving us an idea what we could improve!”. Building and being a product-oriented team isn’t without its challenges. From staying involved with product and design decision-making to encouraging any and all ideas on a cultural level.
Embracing asynchronous communication
If your company is remote-friendly, Asynchronous communication is a significant differentiator in a world where businesses are increasingly remote. Highly capable asynchronous work still allows for and includes at appropriate moments, some synchronous discussion. Asynchronous communication can increase team productivity because synchronous communication requires constant context switching and makes creating large, uninterrupted chunks of time during the workday impossible. When software engineers focussing on their work, they will put *Do not disturb* mode. embrace async communication to your team. They know their responsibility and you also know your responsibility to not disturb your team while he focussing on his work.
How, Who, When to Write Documentation
We know, techy people don’t want to read and write the documentation. But documentation is like a Bible. The Team that has good documentation is golden but too much documentation is like a gold that worth nothing.
Before your team starts their sprint/task at least he knows what to do. Before sprint starts, break down the task list, put a clear description and work of scope and add additional documentation like Development Guideline, API Spec, UI/UX Design, Flowchart, Database ERD, and so on. All of those should be well prepared before your team start on their work. So you need to know how to write simple documentation but easy to understand, who will write it? and when to write and deliver that documentation to your team.
Good Documentation will help your team to reach the same goal
KPI is Matters!
I said again, it’s matters! How you will measure your development team if you don’t have a standard KPI? Measure by Git commit, task activities, and Velocity it’s not enough. If your team wants to meet its goals, then you need to ensure that you have set up objectives for your software development team to achieve, and, in order to measure these goals, you need to use software engineering KPIs. When properly used, these KPIs can help your team become more productive and create a higher-quality product. Your KPI should be Measurable and Actionable
Sometimes you create a task list only related with feature development. But there are so many things that you can measure out of technical things. Small things that your team doing are still worth it. KPI is not only about how your team finishing the task and doing RnD. But also about the initiative, critical thinking that can give good impact into a product, mentor-able people who can help us to do knowledge-transfer to our juniors.
Build Clear Career Path
Career progression is one of the biggest factors to retention. Every job plateaus. Create a career path for each employee to ensure they stay motivated. As a tech leader, you need to discuss this with the management. How they can support those career paths progress for their employee. It will be always relate to your clear KPI’s. Good KPI and Good Career Path Plan will motivate people to work for your company.
There’s another Framework or Workflow that you can build for your team. This is the first step you need to care whatever your timeline and company situation. If you miss the Basic Framework of your team, it difficult to put your team on the same track.
Team Framework Clear, then develop your people!
You are confident with the Framework that you just inject into your team. Your team already follows it. They enjoy it, following development guideline, agile enough and has good asynchronous communication. Until this far you already know what is the EXACTLY culture that you’re trying to build. You can see it with your eyes. But, there are other things you need to do. It is developing your people.
Develop people is not only about hard skills. It’s also morale and soft skills. How you can make a good commitment between your team, influence good things to them, make them more Loyale.
Let’s start with building trust, giving everyone space to be welcomed as a human being, embrace conflict, by challenging people to apply radical candor and fight with each other for the same goals, show commitment to the team and the team goals, thereby DEFINING SUCCESS ONLY FROM TEAM LEVEL.
Until this phase, you need to build a strong atmosphere for your team. Influence them. Set specific goals for the team together. You can held a small event once a week for your team. Let’s say “Friday Upgrade!” the two hours event that will be sharing about the best practice of coding, or maybe sharing about new technology or maybe a monthly hackathon with good reward. This event is part of Continous Knowledge Transfer and Continous Learning to engage your team more deeply and bringing more enthusiasm.
Last but not least, is Choosing Technology Stack
You and your team need carefully to take any decision to choose the right tech stack. Let say you already release your MVP. Then you need to scale it. Not Easy but also not Hard. Unfortunately, there is no uniform effective technology stack. But at least You already have two fundamentals for your team. Good Framework and Good Environment resulting spirit for Research and Development on your team. You have seniors engineers and junior engineers on the same pit stop. Loyal people will giving more. Making RnD more easier. In your dynamic environment, they will be more initiative and spent their time to research about new tech stack. Doing some benchmarking and give a presentation to the team about some new technology. When they feel comfortable working on your company with a great environment and feel geot appreciated, it’s a pleasure for them to *volunteering*. Your team will growth so fast, solving the problem and coming with good solution.
Throughout entire my life built my tech career and manage so many people, People come and go not only about salary. but it’s about Environment. They want good Leader, fair work-life-balance and dynamical challenge.
Yes! Read and Learn about The Lencioni Method for the remaining part of the pyramid that I create. It’s adopting the same method.
This article can be summarized: To build a great Software Engineering Team. Focus on the Framework/Workflow and Environment First. Make your team feel more comfortable and engage them deeply to build trust and enthusiasm. The only common big problem for any company in the world is losing their best talent. You can’t try to appreciate someone on their way out. It is a little too late. Your employees are your most valuable asset. Don’t take them for granted or treat them poorly. Loyalty is a two-way street.
All of those can be done in one night. It’s a three-way collaboration between you as a tech leader to build a clear vision for your team, with a company that can support what you’re doing, and also a collaboration between you, the company, and your team to make a big commitment and staying on the same track. Once you break that commitment and ignore some points above, your team will be shaky and become unstable. Again, Building Software Engineer Team is like planting a plant. You need to take care of it every day.