In addition to overall architecture (let’s not argue about what that means) my role with my current employer involves a lot of higher level operations responsibilities. So I am a stereotypical non-coding architect…who doesn’t even to get to do much architecting! However recently I’ve wormed (forced!) my way onto a couple of projects where I have actually got to use my atrophying coding skills. That explains the recent flood of technical posts. This one is going to buck the trend.
I am a strong believer in balanced teams (different levels of experience and diverse backgrounds) because I have fund that this tends to result in the best solutions. But why exactly does experience matter? For my purposes here I am going to ignore the technical aspects and focus on some “softer” benefits of having been there before:
- Experienced people are not afraid to be wrong.
They have been wrong before. They know that they are going to be wrong in the future. Every day you need to make decisions based upon imperfect information. When the decisions are big it’s easy to become paralyzed. However once you come to the realization that you can only do the best that you can with the inputs that you have things become a lot easier. And making these decisions with confidence (not arrogance) is important too.
- Experienced people are not easily flustered.
Let’s face it , once you’ve been round the block a few times it’s pretty much guaranteed that you’ve been in some horrible situations. And yet the world has not ended. So when life throws one of its infamous curve balls you simply compare the current disaster to those that you have survived before and think “I’ve seen much worse”.
- Experienced people know when to push back…but equally they know when to stop pushing.
We’ve all seen it before. “And when the user presses this button I need dancing penguins to materialize and…”. The ability to constructively question the “business value” is critical to any project’s success. Everyone is different and users and no different. Over time you’ll pick up a variety techniques that work for steering the different personality stereotypes in the right direction.But there is a second piece to this, knowing when to stop pushing. No matter how skilled your customer management skills there will always be things that you need to do that you don’t like or that don’t make sense. My advice is simple – get used to it!
It difficult because every time anything happens that supports your previously ignored opinions it’s very easy to fall into the “we should have done it my way trap”. This can be very destructive because the negative energy can adversely affect not just you but the entire team. I’m not saying that you shouldn’t vent about the fact that you were right and everyone else was wrong…I would not want to deny you that pleasure. However vent and then quickly move on.
Thnx that was a great article…
Good post, Jason. I think you left one off the list that you briefly mentioned: knowing strengths and weaknesses. I’ve found that combining a mix of experience and backgrounds on a project team forces a mix of strengths and weaknesses that the team must balance in order to get something accomplished. This is where the experienced folks can deliver a lot of value — when the time comes to allocating who does what.
My number-one complaint with developers is that they do not push back enough. The long history of spec-based development has hurt even experienced developers in this regard – many have never learned to push back.