Ask HN: What are some things your software team does that makes it successful?
I'm about to run a software team after being a developer for a few years. I've read the "material" such as "Peopleware".
I'm interested in concrete tips that you feel have made your team successful in a startup delivery oriented environment.
It doesn't have to be about software.
5 comments
[ 3.3 ms ] story [ 24.9 ms ] threadWhether it's communicating about bugs, tickets, issues we've encountered, bugs or talking about how drunk was someone this weekend or where we'll go for lunch. I've seen lack of communication cause issues that snowballed into huge combination of hours and money spent * stress and willpower. If you're going to lead the team, don't be one of those silent guys that nobody wants to ask something because they know they'll get a CS lecture and "mental negative points". Be accessible to your team, create a positive, relaxed atmosphere, be open to ideas and suggestions and with good communication even the worst crunches will pass like nothing.
Other than that:
* Proper git usage
* Defining how we work (architecture, style, plugins)
* Code reviews
* Static analysis - no people blame, machine told you that code sucks
I have been running a consultancy for 15+ years without much success, then this january I changed some elements on how we worked and wrote a manifesto about what is most important for our company, this has made a huge change in how or success and the sustainabillity of our business.
This change has since evolved into the TimeBlock method, a simple method that takes 30 minutes to learn, a couple of weeks to be comfortable using and probably a lifetime to master.
The methods manifesto is about Transparency, Planning, Sticking to the plan & Learning from our mistakes.
You can read more on http://timeblock.com or email me : anders (at) timeblock.com
If you find it interesting and want to learn more I'll gladly take a skype call explaining the method in details.
I have lead a number of teams, and I can say I have had more than a few people on each tell me they would work for me anytime, anywhere. The prime reasons so far have been 1) I will never ask them to do something I won't. 2) I will defend them first, my ass be damned. 3) I respect the team dynamics and trust them to do their job while I do mine which is keeping people off their back.
learn your team and respect them. work at earning their respect. don't expect more work out of them than you put in. if you assign a dev 3 issues assign yourself 4. if that's not possible go out of your way to be transparent. developers are motivated by progress and want to see deliverables; so transparency about where you spend your time can help, especially at first.
create an environment where it's ok to fail. both with software architecture and human challenges. avoid creating an environment where people can't communicate or ask for help.
don't be passive aggressive, always be direct. be light hearted and have a soul, but don't get stuck being too nice and let that prevent you from being firm as needed. try to balance this out with letting people occasionally make their own mistakes and learning from them if it's in an area of the project that can afford to invest time in this learning. sometimes you can to force a good decision by being firm, but if you can let it evolve organically the person will feel they achieved more.
try to do your best work and encourage that in others, but always calculate some buffer for things not always running at full tilt every day.
good luck!