Pranav Kasetti
Software Developer
What makes great software development teams
Why this post?
I've been fortunate in my short career so far to have worked with a variety of software teams across industry sectors. I am writing this post to reflect on what I learnt from each team that I've worked with. I have learnt a lot along my journey, and I tried to take something positive from every experience I've had at work. No job is perfect, but I've always learnt from every experience.
This is a selfish post in some ways because I hope that by writing down everything that I've learnt, I can avoid unenjoyable jobs in the future and learn to thrive across a variety of environments. However, I hope that what helps me could also help you if you are looking to find a good job in the IT sector, or change a culture (you have to be senior+). This post is a generic reflection on how to improve teams, and does not imply any of my past employers had these issues.
Full Disclosure: I've worked for a fintech SME with a small Scrum team, freelanced with another developer for a video-editing app startup, contracted for a healthcare app, developed an ML web app with my university group, and worked at a high-quality software development agency all as an iOS Developer.
Without further ado, let's now dive into what I think makes an amazing team.
What makes great Software Development teams?
- People
- Product
- Processes inc. Agile
- Culture
People
The best companies hire the best talent. There's a reason for that, and that's why I consider people the most important factor in a team. People are the currency of a business. Even if you don't have the other 3 factors, they can be easily developed with the right people. I find soft skills alongside leadership skills have just as much of an impact on success as the technical skills. People don't leave bad companies they leave bad managers.
The best people give back more to the company than their salary. The first employees lay solid foundations for the culture, development practices, processes and the organisational structure. I personally think hiring the best people you can with a competitive salary is worth the extra effort. Early employees act as multipliers by encouraging more talented people to join, and maintaining high-quality product development.
Examples of malpractices:
- Management trying to cut costs by rewarding developers based solely on velocity as a KPI metric. This can be avoided with a manager who understands the technical side. Effects of this practice are stressed out developers, neglected software craftsmanship (code quality) and passion drains. Even if you are faster in the short term, technical debt can easily spiral out of control. Martin Fowler explains this thoroughly in his blog. Hiring the best people early helps keep debt manageable, and improves code quality.
- Toxic cultures can be perpetuated by bad managers. Behaviours include workplace bullying, discrimination, singling out people in meetings, not recognising good work, paying a significantly sub-market salary and over-extended working hours.
- Company has too much bureocracy and a closed culture. This is ultimately led by the CEO, and feeds down to the lower levels. Companies need to be open to feedback to innovate and thrive in the fast-paced software world. Apple is famous for being siloed by expertise, and you can't argue with the success of their products. In Apple, key business decisions are delegated to the relevant experts. The best ideas should win, rather than those with the biggest title.
- Any kind of unlawful practices.
The best ideas should win, rather than those with the biggest title.
I personally think meritocratic cultures are the most rewarding to work at because they produce the highest quality work. In this way, people are the resource that really drive the company.
Good Developers
Here's my formula for a good developer:
Talent + Character = Good Developer
Character is the more important trait imo. Even if a developer is talented, they may not be good for a team if arrogant, and hard to work with. On the other hand, if a developer is weaker technically but easy to work with, they can upskill, perform better with time and will be grateful for the training provided.
A good developer keeps their ear to the ground to identify wider problems in the project in addition to completing Jira tickets. With experience, seniors develop skills beyond everyday coding, what I call project awareness. Awareness directly prevents the same mistake happening twice, from experience.
Product
Having a great team only makes sense if you can support them with an impactful, valuable product. Apple is able to hire the best developers because they make enough revenue from their best products.
- Validate the idea thoroughly with an MVP.
- Raise investment.
- Build early version with good developers (balance budget with quality).
- Grow revenue.
- Hire more developers.
Creating a great product without great people can be a chicken-egg situation, but once you've validated the idea and have a great business model, then you'll be able to get the best talent either organically or through recruitment.
Once you have a great product, or brand, you may find that talented developers WANT to work for you. An example is PSPDFKit. Peter Steinberger bootstrapped his company with his own development skills, and now attracts the best iOS developers because his developer brand is inspirational.
Processes inc. Agile
I've highlighted this point because I believe processes are pivotal to the success of a company, as a form of automating best practices. I won't repeat the mandatory Joel on Software reading, however this section builds on the article.
Ideally, we enforce code quality through a combination of:
- One-step build process
- Linting
- CI + Tooling
- Testing (Unit, Integration, Acceptance)
- Architecture
- Design Patterns
- Documentation-Driven Development
- Regular Refactoring
- Pair Programming
- Pair Designing
Developers can measure code quality themselves, and they can readily tell you when they find code unpleasant to work with. Code quality can be enforced through stable, robust processes. Each project can standardise and document as much as possible to save time for new joiners, and maintain code quality / consistency as the company scales. Documentation includes domain-specific knowledge as well as the processes.
I am a fan of Agile software development (Scrum), because the team could easily visualise project evolution, respond to changes and track issues in a responsive project management framework.
Huh, what is Agile?
Don't worry. We've all been there. See the manifesto for a quick primer on the principles derived from Scrum and Kanban. Those links can explain the topic much better than I can, and also there's too much to talk about for this post.
Fun fact #1: I've linked to Atlassian's pages because they invented Jira - the #1 software development tool used by agile teams.
Fun fact #2: Agile Software Development was invented by Kent Beck and Jeff Sutherland (semi-famous software developers of the 90s) because they found these principles improved processes in their projects.
Why Agile?
I've worked only in Scrum teams so far in my career, so I'll limit my answer to Scrum w/o refs to Kanban (CD).
Agile is a powerful project management method, and works well when talented teams of management and development are aligned. Scrum enables us to respond quickly to changes in project scope, track issues with ease and continually ship product increments to ensure prompt delivery.
For example, developer productivity can be measured through velocity in Jira projects. For non-technical managers, it makes sense to measure developers by number of features developed because this drives business value. As mentioned previously I don't think velocity is the right metric in isolation, but nonetheless it is useful. Agile standardises process through metrics, team structure, tooling, and regular ceremonies.
One of the principles I live by is:
If it can be automated, automate it.
Agile is a great way to automate best practices in project management with multiple unknowns. Software projects are notorious for their ambiguity at every step of the development lifecycle, including requirements gathering.
CAVEAT: While Scrum has worked well for me in Startups / SMEs, do note that a Waterfall methodology may work better for larger teams. This is because they are acclimatised to that cycle, do not need to innovate as fast, have bigger teams to handle workload, and the company may not need to continually ship major features.
Supportive, Open and Learning Culture
The final point I want to cover is how to select/cultivate culture. Culture is important to employee satisfaction, but requires care to nurture. Company culture is reinforced by every employee, which is why one of my mantras is:
Take care of all the little details, and the big picture will take care of itself.
That especially applies to hiring decisions. A bad manager is not worth any salary in my opinion, and is hard to displace once they are that senior. Good companies take care in every decision, and pay attention to detail. Don't join companies with bad managers. I talk below about how to scope companies out before applying.
Good developers follow a detailed, meticulous approach with SOLID, FIRST and Design Patterns for writing code. Passionate developers also strive to write the best code they can, keep learning and are dedicated to their job. The same culture of commitment, and dedication should permeate in software, and the company relationships.
I am not a great programmer. I am a regular programmer, with great habits. - Kent Beck
Great cultures can cultivate great habits. Great habits are what drive great success. So yes, I may be sounding OCD, but I firmly believe in Murphy's Law. xD
Honesty, openness and supportiveness make a company a joy to work at, even if the projects are not as exciting. It's all about belonging to the team, trusting the team, believing in the mission and delivering high quality work. I get motivated to work when I feel part of the company.
It's easy to gauge whether the company has a great culture through regular employee engagement and satisfaction surveys. Rather than getting upset about poor performance, the best companies (read Creativity Inc. for insights into Pixar's culture) act quickly when a problem comes up and engage the whole company to improve. Self-evidently best done early.
Culture is a hard metric to gauge from the outside if the company is very insulated, however, we can get a glimpse beforehand with Glassdoor reviews, TrustPilot, website, and researching the management team.
The best companies support employees to upskill, fund them to become certified, give them clear progression pathways, offer them opportunities to blog articles, speak at meetups and feed their passion. My purpose is to write code, and if you support my development, I will work my best. Everyone needs a work-life balance, so join a company that supports you with a healthy lifestyle.
We rise by lifting others.
Even with the best people, product and processes, there WILL be problems. This is not an issue in itself, when the culture is supportive and open. Writing poorly architected code is bad performance. As mentioned before, speed and quality need to be balanced. That doesn't mean fire the employee though. It means openly talking to them, understanding their situation, supporting them and, if needed, improve the processes to prevent repeating the mistake.
Don't blame the person. Blame the process, and improve it.
Simple things like providing great salary, gym membership, pension, health insurance and similar benefits make the job enjoyable for employees and can even foster loyalty. Companies should not abuse loyalty because it's easily lost with the wrong behaviour. Every member of the team (including management) needs to belong and feel supported by their teammates. Hire good managers because:
If you take care of your team, your team will take care of you.
I mentioned before about meritocratic cultures. I like working with no egos in a meritocracy. Developers spend their whole day writing code, and working with lots of technical debt can drain passion and energy over long periods of time. This is why I advocate for software craftsmanship to be enforced throughout the company. Pride in your work fuels success.
I also recommend scoping out the company at interview. Try and get your questions answered, and I've found I can tell a lot about a culture from how they interviewed me. i.e. how hard they pushed, friendliness, technical detail etc.
Even if a company offers a great salary, I would trust your intuition if you discover red flags during the interview process. Happiness is more important than money.
Summary
From the companies I've worked at, there have been great aspects to every team. I enjoyed jobs the most where I felt supported to grow, learn and was surrounded by passionate developers.
For future companies I work at, I am definitely going to aim high to try and get into the best companies. The best companies are the most competitive because they have the best people, product, processes and culture. You can't measure these things and you can't put a price on them.
My ideal job works for money, and for pleasure. I have been lucky to enjoy most of the jobs I've worked in so far, and to have grown from each experience.
Trust in yourself and your abilties, you are more capable than you realise.
My advice to new developers would be to be selective about which companies you want to get into, prepare extensively for their application process and do your best to get in. Don't doubt yourself before you've even tried.