A frequent and sometimes loathsome responsibility of mine is to pour over resumes when looking for enterprise developers - either for employee positions or contract positions. I say loathsome only because there are some really bad resumes that come through - I fear that bad smelling resumes are too common in the technical field. But people are important, so I actually think this is a very important responsibility of mine. I thought I would share some thoughts in hopes of improving my (and your) situation...
Do not put your laundry list of every tool you have ever touched at the top of your resume. Put this at the end. I skip right to experience because I want to see what you have done, not what you think you know or want to advertise.
Do not make your laundry list of tools take up more than 1/4 of a page - I have seen an entire page devoted to this and it's ridiculous.
Do limit your resume to 3 pages - but the best candidates can produce a quality 2-page resume. Your resume needs to be human scannable and at a summary level; the purpose of interviews is to go into details.
Do explain what you did, but do it by explaining your responsibilities and how they related to the responsibilities of others on the team. You will likely be interacting with a lot of people in your new position, and you get points for showing that you get the fact that relating well on a team is crucial.
Do write with good grammar and communication skills. High quality communication is turning out to be a key differentiator in the current market.
Do seek the advice of a technical writer or another page layout specialist for good formatting on your resume. There is no Jalopy for your resume, and it needs to look better than your code if you want it to be scannable. (Clue: bolding and highlighting and underlining key words actually makes it harder to read.)
Do not include a career goal - I don't know why, I just always thought that was weird.
Do not have a cover page - again, you should only have 2-3 pages total, and each one should be content-rich. (Clue: decreasing margins and using small fonts increases the volume of content but not its richness.)
Do know where to drawn the line on lying. Everyone exagerates on their resume, and I am not so naive to discourage that behavior. But be prepared to explain everything on your resume in an interview, and understand the difference between exageration and dishonesty.
Curious if others in my position also have thoughts to share on what you like or don't like to see...
I had an interesting conversation with a personal friend the other day, and thought I it related well to some leadership issues in the practice of enterprise architecture...
My friend and I were watching our kids (all under 8) skate around his backyard ice rink. Our kids also play organized hockey (disclosure: I coach two of their teams) - for those who do not live in a hockey state or country, ice hockey is a notoriously over-coached sport with extremely high performance expectations at a young age. But we were commenting that this is where they really develop skills and have fun - pick-up pond hockey with their friends. Our kids play for hours on end like this - skating hard, organizing their own teams, setting their own rules and we hardly ever have to intervene (indeed, usually only do so when asked).
We also talked about competition in youth sports. My friend coaches youth baseball in the summer with many of the same kids, and lamented the fact that the kids were extremely competitive with each other within the team - to an extreme that was not constructive. Some kids who saw others get hits would feel more disappointed about their own performance - as if the performance of others somehow diminished their own. He struggled with how to coach them through that experience, and encourage a more positive atmosphere.
Here is where he blew me away - my friend is the classic traditional and natural athlete. He played high school baseball, football, and hockey and played division 3 hockey in college. But his comment at this point was that he wanted to create more of a skateboarding culture on his baseball team!! (disclosure: I grew up a hardcore skateboarder) He felt that skateboarding and other extreme sports create a more supportive atmosphere amongst competitors, where kids encourage and inspire each other to perform at higher levels, and just plain have more fun.
He ran this thought by our elementary school gym teacher, who commented that the reason is because there are far fewer coaches and parents involved in skateboarding - the kids organize the activity. When left to their own devices, kids are inclined to have fun and be their own motivators. I challenged my own stereotypes - these were two people I never expected to hear lauding skateboarding culture! But I was pleased, and I agree with them wholeheartedly.
The Agile methodology has the concept of an Agile coach on teams. It's a thoughtful concept, but coaches can be constructive or destructive. The Agile coach is a well-intended idea to replace the traditional technical lead, who usually becomes a decision-making bottleneck, with someone who guides and inspires the team. But the team is empowered to make its own decisions and be self-organizing. Good coaches are extremely aware of the game, but don't need to control every move. Good projects should play out like pond hockey - teams are self motivating and invite oversight rather than struggle to perform under its weight.
Do you have a skateboarding culture in your organization? Or are there too many parents and coaches involved?
Does your performance inspire and encourage the performance of your peers? And do you feel inspired and encouraged by the performance of your peers?
I have been wanting to follow up on various very good blogs posts I've been reading lately around architecture concerns with Saas/mashups. A lot of people bring up concerns on security, etc. when talking about Ajax and the new mashup technology - but old schoolers will say the song remains the same. Sure, there are some new exposure points and those need to be protected, but you primarily need to practice the same good core architecture when dealing in this area.
I fully agree with Robert's comments on reliability and other -ility management for SaaS/mashups as core architecture principles. I think his experience is an interesting case study from a couple of standpoints - one is that presentation tier/mashup developers obviously need to think about graceful error handling in the UI layer in a new way (not sure if that's being done generally), as well as logging and outage reporting (highly doubt that's being done fromt clients as it's not as easy as server-side). What is the common Saas model for this? Does a mashup developer need to setup his/her own monitors for consumed services? Subscribe to an announcement list? Somehow report from the affected clients?
Too many architects fall in to the trap of believing that the distinguishing value they provide to their respective organizations is in the form of defining and enforcing standards. While there is no doubt a role for standards and governance, these architects miss the fact that their most important role is to define the values of their organization.
When overemphasized, standards can become a death spiral... drawn out cycles of identification (by which time they are no longer optimal), blanket application (leading to loss of competitive advantage in cases where they don't apply), and loss of faith in the architecture organization. Standards too often contribute to the cult of ceremonial documentation, rather than the culture of working software. Fanatical standards enforcers also drive the most valuable innovation in organizations to the underground - it is demonized and ignored rather than cultivated and matured.
The differentiating value of an architect should be leadership and influence, not law enforcement. This happens when architects define value statements that are more durable positions than moment-in-time solution statements. Values have deeper meaning, and empower people in the organization to make independent decisions consistent with a larger vision, increasing agility. They allow for individual ownership of a stake in the enterprise architecture - every participant is a stakeholder.
Value statements and the leaders who promote them encourage teams to explore, report, refine, and share their decisions with the whole. Enterprises always have a mixed portfolio to manage - the most valuable mix will at least reflect a set of core architectural values rather than be a poor attempt at homogenization. Review of the portfolio should not be a witch hunt for non-compliant technologies... it should be a gardening effort to ensure the values are represented.
