A great team of developers, engineers or tech teams in general runs on more than just code – it runs on shared principles, or call it culture if you will. Those are the factors that will determine whether a team will succeed, namely constantly deliver good results, or fail in the long run.
When my number gets called to lead a team, I mostly rely on my instincts to do so. But, at one point, I wanted to give a primer to a new colleague joining the team. So, I had to somehow put into words those little details that we put into practice as a team every day, but had never truly been formulated previously.
This is the list I came up with that day:
- Be careful speaking of being done
- Don’t Overengineer
- Simple & working over fancy
- Nothing is ever done
- Caring over Competence
- Flex the play you made and analyze those you didn’t
- Iron sharpens Iron
1. Be careful speaking of being done#
I’m sure this one will hit home. Almost done, quasi done, mostly done, functionally done, implementation-wise done and my personal favorite, done until proven otherwise. How many of them pseudo-done-states sound familiar? But, done is an absolute state, there is no spectrum. Either something is done, meaning all actions to fulfill the requirements of a ticket, task or feature have been executed until completion and no further action is required or it simply is not.
Of course, the source of diluting the meaning of done is most probably project management and pressure to deliver on time with deadlines rapidly approaching, but it’s on us Engineers to flip the script back to sanity. So, be very specific when speaking of being done with a task or not and create a healthy and honest environment within your team without any need to sugarcoat current status.
2. Don’t Overengineer#
Building software is a one-of-a-kind combination of applying creativity and savvy to solve a set of problems that come up when trying to translate real-world problems into technically representable abstractions (add some lowkey OCD to that, but that’s a story for a different day). The creativity involved easily lets one get carried away during development and get lost in rabbit holes of trying to solve something the best and most ingenuous way possible.
This is where a key distinction between developing software yourself as leisure and developing as a team in a professional context comes into play. But, the best possible way is overkill in most cases when looking at the actual requirements and so would break the bank in terms of effort it’d take. One has to put their urge to be creative and idealistic (in that regard at least) on the back burner to stay competitive.
3. Simple & working over fancy#
While similar to the previous point, this plays a bit more into the notion of tool usage. To improve as an engineer you gotta have a curious nature and be willing to try out new technologies and tools. No cap.
That being said, we again gotta differentiate between an explorative and a professional context where reliable and secure functioning is what it’s all about. Every time you are about to bring in a new tool or technology to your project, be honest with yourself, are you just trying to bring it in “because it would be cool” and nice to try it out. If so, better pump the breaks and stick to the old, boring but most probably right choice of tooling, no matter how tempting the new and flashy one is waving at you.
4. Nothing is ever done#
Now, you might be wondering, “Huh? I thought rule number 1 was all about what being done means and now you telling me nothing ever is done?”. Hear me out. While rule number 1 was about project states and honestly communicating residual efforts for your current grind, we are now looking into the technical lifecycle of software applications. And unless an app goes completely out of use and finally RIPs out, there will always be changes to be made. Updating dependencies for security patches are a given anyhow, but also no application will ever be 100% bug free and function perfectly. And here, we are not even tapping into new or changing requirements yet.
Change is inevitable. That is something that we as engineers just have to accept, to sometimes just leave things as is, knowing that each state is just one snapshot in time over the course of an application’s lifecycle.
5. Caring over Competence#
Mark my words. The moment you and your team have checked out mentally, your project is doomed. No matter the individual skills everyone on the team have, that alone won’t keep a project afloat when nobody gives a s**t about it.
You can out-effort your lack of skillz, but not out-skill your lack of effort.
Caring for what a project is about and how it actually plays out is probably one of the most important requirements to be an asset for your team.
6. Flex the plays you made and analyze those you didn’t#
This one goes back to the all-time great football coach Bill Belichick pep talking his team There’s just no excuse for not applauding your teammates and celebrating as a team whenever they did something well. This is what gets you fired up as a team and will go miles when it comes to motivation and working together on a shared goal.
On the flip side, you yourself should never back off from giving your own failures a close look. Just look into what went wrong, why you made a wrong move and how you would handle it correctly in a do-over. Embrace mistakes instead of avoiding them. Making mistakes is key for your own growth, but making the same mistakes again and again is not only dumb, but also mighty unprofessional.
7. Iron sharpens Iron#
The best ideas are not just born and immediately perfect, they need be developed over time. Don’t dodge having your ideas challenged by your most critical peers, especially when you are the one in charge. Check your ego at the door and aim for the premium solution by mixing in everyone’s take on it. Contesting ideas is always good practice for all parties involved to reason about pros, cons and tradeoffs, which again is a key skill as an engineer. Also screw authority & hierarchy during that exercise, it’s about best and most solid reasons for a decision.
DISCLAIMER: While this can lead to some minor and playful butting of heads, don’t brush off your teammates’ feelings and stay empathetic and respectful at all times!