How I build world-class developer teams
My journey navigating the complexities of the software industry for a little over a decade now — from large corporations to agile startups — has allowed me to nurture a distinct set of values. These values are my North Star guiding me in building world-class developer teams, a compass I frequently use to stay the course and lead by example.
These values are a testament to the triumphs, utter failures, celebrations, and candid conversations. It’s about calling out the times when we embody these values, painting a vivid picture of success. But it’s equally about those moments when my team, especially myself, might stumble and miss the mark. The list I have cultivated does not cover the whole kaleidoscope of the intricacies of software teams, but it should add color and clarity to my journey.
I should also mention these values were not provided by my current or former places of employment. These values are mine, not a corporate poster lifelessly hanging on the wall next to the “hang in there” cat poster.
The workplace should be a haven of security — an environment where you feel safe regardless of race, religion, or favorite Star Trek series. (The right answer is TNG 😉).
A space where ideas are exchanged, and collaboration flourishes, can only be fostered if everyone feels secure enough to voice their thoughts and concerns. Harassment has no place in the workplace. Whistleblowing should not just be tolerated but applauded and recognized as a courageous stand for integrity and safety.
At first glance, this might seem obvious. Yet, it must merit a spot on this list, and the first one at that.
Communication Not Excuses
Teams miss this all the time. It is human nature to be defensive when you are on the hook for something. Own it with communication!
For example, I don’t usually mind if a teammate needs a day off as long as it doesn’t become habitual or affect the rest of the team. What matters is timely communication. Informing the team in advance helps keep everything running smoothly.
As a second example: If you’re a developer and realize the entire codebase needs refactoring, discussing this with your team before taking action is essential. The decision and its rationale should be shared upfront, not just explained after the fact.
While there are numerous situations you can consider, the main idea is clear: embody the role of a team player. If you need something, talk about it. Don’t wait until it escalates into a problem only to offer excuses for why something did or did not happen. Let’s put communication first and excuses last.
Buy-In Requires Weigh-In
This one might seem like a no-brainer, but it’s easier said than done, especially if you’re a seasoned developer who’s found comfort in familiar patterns and languages. It’s akin to having a cozy armchair in your living room — why would you want to switch it out? But then, some developers are more adventurous and are always looking to push the envelope.
It is those fresh young wizards of code who dare to challenge existing norms. While their lack of experience needs tempering, it is that same lack of experience that brings fresh ideas and perspectives that dev organizations need to be a best-in-class development team. A good junior can be an exceptional value add.
Lean on Experience
There’s a balance to be struck, a dance to be danced. Older developers may sometimes find it hard to tune into the frequencies of the younger ones, which can be a hurdle on the road to progress.
On the flip side, young engineers should also realize when it’s time to borrow from the wisdom of their experienced counterparts. Engineers should be attuned to the failures and successes of those who have already walked the path, and doing so will speed up development and save you from disaster.
Humble Waffles, Not Ego Waffles
Both junior and senior developers and members of the same software team must keep their egos in check. If there were any waffles on our metaphorical breakfast table, they should be humble, not inflated with ego.
Senior developers should make space for juniors to express their ideas. Conversely, junior developers should not overvalue their knowledge. Acknowledge that advice from experienced colleagues often comes from years of hard-earned experience. Steer clear of ego and instead foster a culture of collaboration and respect.
Consistency Over Correctness
Stumbling upon a shiny new pattern or mechanism, you might be tempted to go bananas and splash it everywhere like a toddler with a new box of crayons. But beware! Such unchecked enthusiasm might lead you into the labyrinth of spaghetti code.
The secret sauce? Consistency. If a new method catches your eye, take the time to implement it across the board. If that’s not feasible, perhaps it’s wiser to leave things as they are for now. Remember, steady wins the race!
Consider Compounding Interest/Effects
Small changes and compact merge requests are like delectable bite-sized treats — easy to consume, review, and they leave less mess.
Plus, their blast radius is comfortably small. Over time, these minor shifts accumulate like grains of sand. On the other hand, large changes can be more like a surprise pie in the face — messy, startling, and a bit too much to handle at once. Let’s embrace the art of small, consistent steps toward a larger, more impactful future.
Don’t Play With Dead Snakes
Once a decision has been made, the snake is dead — there is no need to keep poking it.
Don’t keep raking up old choices and stalling progress unless there’s a compelling reason to rethink your course. Embrace the decision made, even if it was tough, and move forward. Just like a hiker on a trail, you must keep marching. No poking at dead snakes, please!
Just Kill the Snake
Have you ever found yourself locked in a duel of opinions about a certain approach to a problem? A recent tussle in my memory was the debate between using JSONB and ad hoc tables for creating custom fields. Both sides had their merits. My colleague was a staunch supporter of one, while I was inclined toward the other. After much verbal jousting, we were at a stalemate. Yet, progress demanded a decision.
This was a debate that could have stretched over weeks. But for the sake of forward motion, a decision had to be made, especially when the difference in impact between the choices was relatively small. So, in a similar situation, remember not to spend too much time on debate, especially when the stakes are not sky-high. Take the shot; kill the snake!
The tech industry, especially software development, is constantly evolving. Emphasizing the importance of continuous learning to keep abreast of new technologies, techniques, and methodologies can be very beneficial.
Also, focus on innovation. While consistency and sticking to proven patterns is important, so is the ability to innovate. A balance needs to be struck between the two. Innovation can drive efficiency, quality, and lead to new and exciting products and features.
Resilience in the face of failure and setbacks is crucial in software development. Projects might not always go as planned, but the ability to bounce back, learn from the experience, and keep moving forward is invaluable.
Be accountable for your work. Taking ownership and responsibility for one’s actions and work, acknowledging when you’ve made a mistake or when a task/project didn’t go as planned, is important for maintaining a healthy and productive team environment.
Adapt. With the ever-changing tech industry landscape, being adaptable to new situations, tools, and changes in project scope or requirements is a valuable skill and perspective.
Sales-Driven, Not Sale Driven
The software being developed should ultimately meet the customer’s or end user’s needs. Keeping their needs and experience at the center of decision-making can lead to a more successful product.
Focus on all your customers. Sales teams are notorious for promising feature development for singular customers. This can create an environment of singular features that are only helpful for a small subset of the users. If this is happening, speak up!
This set of values and insights is far from exhaustive. They serve as my guiding principles, ones I refer to often, drawing strength and inspiration for challenges encountered. They are those that I have written on my whiteboard for continuous reference.
Remember, this isn’t a monologue — it’s a dialogue. If any of these principles resonate with you, if they fuel your passion or provoke thought, then my mission is accomplished. If so inclined, spill your thoughts in the comments, and let’s keep this conversation going. Because, in the grand tapestry of software development, every thread matters — every voice counts.
Code of Honor: Unveiling My Software Team’s Values was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.