Archive for category Career Development
There’s no emotion in business
Posted by cgrant in Business, Career Development on September 16, 2011
In the 1992 movie A league of their own, Tom Hanks (the coach) emphatically berates one of the female baseball players saying “There’s no crying in baseball!”. I can almost hear him saying that about business too, “There’s no emotion in business!”.
I’ve always been fascinated at how the professional world is founded on vulcan like logic where there is little room for emotion. Early in my career I was very passionate about my profession and, being green, that translated to emotional driven conversations, and poorly chosen wording to the wrong people. Over time I’ve worked hard to maintain the passion but curtail the emotion. I’ve read communication books, reviewed my distribution list, paused before clicking “send” and have made decent strides over the years to remove the emotion from my professional communications.
Recently I’ve been reviewing another aspect of this concept. Personal communications with colleagues. Take this scenario, you and your buddies go out for a beer, you might mention how work is getting on your nerves and how bob from accounting keeps getting on your case for those TPS reports. Now suppose there’s another guy at work that you go to lunch with now and then. You have the same conversation with him as well. That is proabbly not a good idea.
I’m of the mindset that these more personal conversations probably shouldn’t occur with any professional peers. You may have a decent working relationship with someone where you can be honest about the state of things but even in these situations professionals need to keep their guard up and act professionally.
Here’s a scenario. Jim and I are in different groups but working on a project together. We’ve been on project for some time and have a rapport. One day after dealing with marketing I fire off an email to Jim. “Marketing really is annoying, why can’t they just give us a plan and stick to it instead of changing it every day”. Jim agrees and we move on.
I let emotion slip into my communication though and while I have a decent rapport with Jim we’re not drinkin’ buddies, and even this minor level of emotional conversation sets a tone about me and my professional maturity.
It’s sounds simple and harmless but this level of personal communication will limit your career. Rather than presenting the emotional statement of “Marketing really is annoying, why can’t they give us a plan and stick to it” I might be more professional and say “Marketing is impacting our ability to deliver the project. We need to meet and discuss locking down the plan to avoid these additional costs”
Business favors logic and discipline, and those of us with passion and emotions need to filter our words well in order to succeed.
Coffee Notes: A Better Word for Software Craftsman
Posted by cgrant in Career Development, Coffee Notes, Development, Technology on January 27, 2011
I ran accross this post by Krishna Kumar today discussing how the goal of the Software Craftsman is great but that programmers today don’t care. He notes that many of today’s programmers are in it for the paycheck and not interested in being the best they can be. Kumar discusses how the term Software Craftsman can be perceived as elitist and unapproachable for programmers just in it for the job. I thought this was an interesting point. We want our developers to best the best the can be but are we providing options that are approachable and interesting enough for what they are really focused on.
Krishna continues on noting that organizations need to foster this growth as well. Its one thing thing to have an interested and driven individual, its another to have an organization that fosters and nurtures growth and development rather than simply factory style, assembly line code.
Good read with multiple points. Take time to read the whole thing.
http://java.dzone.com/articles/get-better-word-software
Coffee Notes: 7 IT Career Rules Worth Breaking
Posted by cgrant in Career Development, Coffee Notes, Technology on January 21, 2011
Here’s a great quick read about some career myths that maybe you should avoid.
Dave Willmer really hit the nail on the head with these 7 tips. More than one I need to work on still :)
7 IT Career Rules Worth Breaking via CIO.com – Continuing Education by Dave Willmer <info@cio.com> on 8/1/10
Sometimes sticking to the status quo can actually hinder your career success. Dave Willmer offers some suggestions to help you keep your IT career moving forward.
The Profession of IT Architecture
Posted by cgrant in Architecture, Business, Career Development, Development, Management, Technology on February 2, 2010
The profession of IT Architecture is typically an ambiguous role for most organizations. Management and aspiring architects may not know exactly what the role comprises. In this presentation we review some of the challenges we face understanding the role of architect and how architects fit into the IT organization.
Layers of Architecture
Posted by cgrant in Architecture, Career Development, Development, Java, Management, Teams, Technology on October 16, 2009
There are tons of architects out there today. It seems when you’ve spent enough time as a developer, you end up becoming an architect. Architecture is not just the next step in a developers career. There are whole new disciplines and methodologies applicable to architecture. That said here are the common levels of architecture.
Enterprise Architecture (planner)
Enterprise architecture is a high level field that concentrates on how the various domains or subject areas interact. This layer spends even more time focusing on how technology will be utilized in the future, and governing how it is used today. Enterprise architects work to create technology roadmaps and work with the business to plan for the implementation. Enterprise architects create technology projects. It is at this layer where frameworks like TOGAF and taxonomies like Zachman come into play. This layer view the enterprise as a holistic entity.
Solution Architecture (designer)
A solution is an answer to a question. The question in this case is typically an IT project. The solution architect’s primary objective is to design a solution that meets the projects requirements and also falls in line with the domain and enterprise architecture guidelines. The solution architect is responsible for coordinating with multiple domain architects to design the most appropriate solution. A solution architect may interact with domain architects in infrastructure, web services, data management, and so on. During the course of the project a solution architect will typically create many work products either for communicating the solution to a governance board, to explain the implantation to a developer and various other uses. These work products are eventually owned by the domain architect as codified knowledge of the system after the project implementation.
Domain Architecture (owner)
A domain is an area of focus. Domain architects are primarily focused on maintain a specific area of technology or a specific application. These architects are the owners and gatekeepers for a specific area. The work in this area is primarily concerned with the current state of the system. These architects are charged with managing the knowledge for their area. These architects are also responsible for keeping up to date on future projects related to the domain and guiding the designs to meet the overall objectives of the domain. A successful domain architect will know that a future project will require x functionality. When an active project is debating between two possible implementations, the domain architect will be able to guide solution toward the best of the two solutions that meet the future goals.
Application or System Architecture(builder)
The application or system architect is primarily focused on the implementation at hand. This is the most detailed level of architecture. An application architect, for instance, would be concerned with the most appropriate design pattern to use in a certain programming situations. These tend to evolve from the most advance developers and engineers. The primary focus here is to implement the best solution for a specific task. Work products that may be produced during this layer are primarily used to communicate to the developers or implementers. In many co-located environments a lead developer often fills this role and very few work products are actually produced. Instead the team may utilized whiteboards or code stubs to communicate the implementation. For larger more dispersed projects, or for outsourced solutions, the application or system architect has a more demanding role for providing detailed implantation instructions.
Conclusion
The various layers of architecture are not meant to be isolated entities. In most situations one architect will fill multiple roles at various levels. Each layer has a unique focus. Understanding the layers helps clarify responsibilities, activates and deliverables. From a career development standpoint individuals can use the layers as the basis for a personal gap analysis and learning plan.
I look forward to reading your thoughts and comments.
Best of luck in all your endeavors.

