Does Creating a Personal “Brand” Really Help Your Career?

In the last few months, I’ve been reading and discussing a few different books. One is Chad Fowler’s “Passionate Programmer”. I’ve found his book to be extremely entertaining and in many ways have spoken to me at some level.

I have felt for some time that careers of those I meet (at least a high percentage) are simply “drifting where the current takes them” instead of having a specific purpose. As Chad puts it, they are not leading a career of “intention”. This is one of the first steps to understanding how to look at your career and manage it like a business (with YOU as the product). Intentionally create a brand. That brands sole purpose is to elevate YOU as it’s product.

The question I have posed to myself is, will creating a personal brand, complete with all the trappings of my own distinct personality really help my career move forward?

Well, that is a goal I have set out to test. I currently have a strong, sometimes overwhelming feeling that my career has stalled in some way. I work for a large enterprise leading development teams that write large enterprise-scale software systems. By my standard I am making a good living for myself and my family. I am staring at a good job working with great people. Is that enough?

So now I am taking the advice of Chad Fowler and asking myself – if I were running a company with ME as the product, would I be OK with the results I am getting? Or, would I want to push the envelope, take risks, and come out on the other side with a remarkable product and career? I am feeling compelled to make an honest effort at setting my career and character apart from peers. I would say I am taking a path that leads me to educate myself in every way I can and not rely on a typical approach. As James Bach says, the typical path will ultimately not help you distinguish yourself, but will only place you in a slightly smaller (yet still massive) sea of similar people with very little chance of differentiation.

Interestingly enough, when I pose these tough questions to myself using Fowler’s advice as a backdrop, I always have the same answer.

Servant Leadership and The Superperforming CEO

Today I was invited to go to a seminar and talk about a new book, “The Superperforming CEO”. The books author, Dave Guerra, found me through a local organization I help coordinate – Milwaukee Agile. When I spoke to Dave prior to the seminar, he mentioned that he was very interested to get more plugged into the Agile community as the concepts that Agile proposes are very similar to that of his book, and life’s study in management and leadership.

The seminar was very interesting and as the talk went on, I found that he was indeed singing out of the same hymnal that agilists are regarding leadership and management. Dave also explores the duality of problems and opportunities that business people encounter. Here are some of the critical takeaways I received from Dave’s talk (and book) that support agile tenets:

  • Super performing leaders share common traits that are pervasive – part of their fabric. They have transformed from managers to Servant Leaders. This models the approach used by scrummasters and agile managers (remove impediments and cultivate an environment to innovate and get the job done)
  • Great leaders understand that getting process well defined without a great culture leads to unsatisfied workers, stifled innovation and broad under performance. They also understand that having a great culture without process control leads to terrible mismanagement and woeful under performance. Similar to agile techniques, these systems need to exist in balance and are ever-evolving. (Manage your processes and Lead your people)
  • Dave spoke of a principle he calls “tacking” similar to that of sailing. Tacking too far in one direction can throw a system drastically off course. Minor, incremental (or evolutionary) shifts in direction yield the best results, and will serve to keep your ship upright as a side effect! Agile often manages this through short iterations, and constant feedback through retrospectives to make micro-changes to the process.
  • Superperformers are those that consistently perform over time. This is similar to the concept of sustainable pace and continuous improvement in the agile paradigm.
  • Superperformers tranform “flow” and consistently look for ways to optimize. Kanban and Lean help in this regard by managing flow of work into the system and eliminating waste.
  • The foundation for Superperformers is “passion”. The passionate CEO will liberate the the teams to become superperformers individually by giving them the tools, encouragements, and environment they need to thrive. This concept is similar to Scrum and self-directed, highly motivated teams.

Over all, Dave did a very good job of highlighting the key principles of the Superperformer and how to begin to achieve or unleash the super performers in our own organizations. The book seems to have some very good detail and touches on a much broader, more tangible set of principles and some steps to take to begin to explore this on your own. I will try and read the text this weekend and update the post. On a personal aside, one of the things that struck me about Dave personally was his authenticity and his willingness to “want to help”. I think he does see the value in the concepts of servant leadership, and is putting them to use in his own career as he tries to spread the word of his life’s study.

Do Developers Need to Work on Their Bedside Manner?

I was recently asked a question regarding our developers and whether they should be representing the IT groups on conference calls with senior leaders. This is a very interesting question. Common stereotypes suggest that a developer has problems relating to people, often using lingo much too technical for their audience, blowing by business issues and going straight toward technical concerns as the primary objective.

In my experience, the results are varied. For some, this stereotype definitely holds true. These developers mere presence on the call means there are highly technical items to discuss, and you will be discussing them whether you want to or not. This type of person typically makes it difficult to focus on the core issue and a potential resolution or decision. The other type of developer I run into –slightly more regularly– are those that have a very good grasp of business concerns. They have attended enough business discussions and requirements gathering meetings or demos to get good at understanding of the level at which business partners interact and converse. This person is very relaxed, confident, but not presumptuous about another persons ability to comprehend or even care about highly technical concerns. I think this type of developer has worked on their “bedside manner”.
Bedside Manner
In medical parlance, this term means that a doctor brings the conversation to the patient, and does so with a human-centered, respectful mindset. Essentially it means they can “communicate” with their patient. A basic encyclopedia definition of the term says, “A good bedside manner is typically one that reassures and comforts the patient. Vocal tones, body language, openness, presence, and concealment of attitude may all affect bedside manner.”

I cannot think of a better term to use to describe what I feel is a skill that ALL developers and team members need to master. Why? Well, I can think of 4 reasons why a good developer “bedside manner” is important to the agile software developer.

1 – Communication is King!

In today’s complex technical landscape, communication is king! If we as developers don’t have the ability to communicate changes, inquire about a business person intentions, seek clarity, and help the customers refine their needs, then the promise of agility is lost. It is even more critical today that we as developers and team members are able to communicate in the language of the users. This is evident from our daily interactions in stand ups, through our ability to help craft artful user stories.

2 – Teams, They Are a Changin!

On agile teams, more often then not a non-technical business person is part of the team. When that is the case, every conversation cannot revolve around the most granular, hard core technical topics of the hour. In fact, even without business people in the room, an agile developer is more likely to encounter the need to converse in the language of the business when discussing requirements with BA’s, or exit/done criteria with testers and QA.

3 – Which One of You is the Architect?

The roles on a software development team are continuing to be blurred. Developers can no longer be insulated from other roles in the organization. When problems are brought to the team, we can no longer hide behind the one or two developers who “are good in front of the business”. We are ALL in front of the business. We all have similar titles and multifunctional roles, not to mention responsibilities for demoing working software. At no point can we feel like communication can be left to the team lead or the architect. Those roles are being blurred and we all need to pick up those characteristics to be successful.

4 – Shameless Self Promotion

Developers need to be aware that communication and successes with business partners also affects their ability to be promoted and make more money. This one seems obvious, but to many developers its not. I can’t tell you how many “one on ones” I have been in where a developer will say, “Communicating isn’t my strong suit. Just tell me what to build and I’ll build it!” This is wrong on so many levels, but the main one is this: communication is part of the gig. If your code is elegant, and your solutions are brilliant, but don’t address the business person need, we are still NOT delivering value. If you want to do that type of development, go work in academia or do research. In the business environment, the organizations ability to realize value hinges on our ability to extract the essence of a business persons desires for a system, and codify them for our customers. And at the end of the day, if that runs smoothly, everyone is rewarded.