As a software development company, it’s easy to focus on technical excellence while forgetting that a lot of what creates that excellence isn’t technical in nature at all. Culture, practices, and all those ‘soft’ things in and around the technical heavily influence the way software gets built, and the quality of output.
With that in mind, and believing that the most valuable things I’ve learned in the last few years aren’t all related to technical expertise, I decided to ask some of my colleagues the one most valuable non-technical lesson they had learned recently, in the hopes that I would learn some new things myself. Here is what they had to say.
Proper meetings in the correct rhythms are very important. If you’re doing it right then people are like, ‘Yes, that meeting was great and now things are better for my work’.
Stop starting and start finishing. Get things 100% done, one at a time, rather than starting many things and only getting them 80% done. Work as if you may be stopped at any minute and would need to be as far along as possible when that happened. That way you actually deliver real usable value into the world as often as possible.
Remember what you can do in a moment, and just focus on that, even if you are on a tight deadline. Just focus on that one next step that you can take.
Collaboration is the key to unlocking good work. Leveraging the people around you and their knowledge is key to progressing.
The most important non-technical skill for a developer is empathy. There is a dangerous and misguided trend in the industry to think of clients (or really any non-developers) in a fundamentally oppositional frame. It is our job to deeply understand their needs and goals and help them get to where they want to be. Empathy is also critically important within our teams, in understanding each other and building a communicative, productive environment.
Don’t be afraid to hold your boundaries when it comes to scope creep and continually changing priorities mid-sprint. It’s also part of your job to let your client know when you believe that what they are doing doesn’t serve their best interests.
Take responsibility for your understanding. As much as it is one’s responsibility to clearly communicate, it is just as much one’s responsibility to understand what was communicated to you. Take the time to clarify, double check and jot it down for future reference. Writing out my understanding and sending it back to someone (be it a client, developer or designer) is a great way of solidifying, understanding and aligning.
Don’t sugarcoat things. No one wants to be be the bearer of bad news to a team member or a client, but beating around the bush serves no one. With clients, if a piece of work is going to take far longer than expected, be clear about this and don’t fall into the trap of “it will just take a little bit longer”. With team mates, don’t be afraid of telling people when they aren’t meeting your expectations for quality or velocity. You will be surprised how people actually appreciate your feedback.
What is the one most important non technical thing you’ve learned?
Nona builds software products people tell their friends about, and teams that keep it that way. If you’d like to soundboard your tech or your team, book a consultation with Ed O’Reilly.