In this article, Shoshana Kordova does a great job of explaining the Hebrew terms rosh gadol (“big head”) vs. rosh katan (“small head”). While telling someone that they have a big head may be career limiting in English speaking circles, telling them they are rosh gadol is paying them a high compliment. Rosh gadol describes the ability to see the big picture as opposed to focusing on the small tasks. Hit up the article for a helpful discussion of the difference in these two types of people and why organizations have (and need) both.
Years ago a great post on the Joel on Software blog discussed how developers would ideally be rosh gadol. In reality, your team will consist of both rosh gadol and rosh katan resources. As a project manager or technical lead, identifying which type of thinker each team member is can help you guide them towards tasks they’ll be more comfortable and efficient with. It might also help you manage your expectations when dealing with these two types of individuals.
I attended the Leadership Resources Celebration of Success this morning. Among many good take aways stands out a short session I participated in with Deb Buhro from Oxbow Animal Health called “Fail to Succeed—How Failure Holds the Secret to Success.” Deb talked about how important failure is to achieving success, relaying some of her personal professional experiences. As professionals (heck, as people) none of us wants to fail. It feels bad and costs us time, money and energy. The mind blowing realization here is that, by simply viewing failure as an investment instead of a waste, we have much to gain from failing (as Ms. Buhro adeptly pointed out during our session). We can turn our perception of failure on its head.
In a karmic coincidence, when I turned to Netflix over lunch to finish a documentary I’d been watching on Steve Jobs, I restarted movie at the point of Jobs’ ouster from Apple in 1985. He was so bitter that he’s sold all of his Apple stock at a low point for the shares. He could have taken his millions and moved to India to study Zen. Of course, we know the story that follows: Next Computer, Pixar, return to Apple, joy and billions of dollars ensue and the world becomes “magical” while Apple’s products become “insanely great.” Learning to fail successfully (or “Fail Up” as David K. Williams puts it in this article) is a hallmark of successful people.
Thanks to Leadership Resources for hosting this great event today and for providing effective, focused and approachable leadership training for the city of Lincoln.
During a recent customer design session (combination requirements meeting and design discussion), I was surprised when one of the stakeholders quoted me as saying that it was the development team’s job to build whatever the customer wants. I paused for a second and thought, “What did I say that was interpreted that way?” I know I would never intentionally tell a customer that our job is to build whatever they want. Our job is, of course, to build what the customer needs. There is a world of difference in those two statements and I took care to explain that difference to all of the stakeholders at the table. Neither of the teams truly knows what the application we’re developing will look like in the end. We all have ideas (at least as many different ideas as there are people on the team). My job as an agile project leader and business analyst is to facilitate communication between all of the players in a way that uncovers customer needs and results in a system that can meet those needs in way that our customers find at least acceptable (but hopefully exceptional).
So many PM articles focus on the nuts and bolts of project management practices. In this post, LeRoy Ward focuses on how to lead projects and project teams. I can’t agree with the need for authenticity enough (sin #5). As one of the commenters points out, being authentic is about being the genuine you. You don’t have to highlight your warts for everyone to see, but it’s OK to admit that you don’t know the answer while also demonstrating confidence in your ability to figure it out (hint: that doesn’t mean you have to do it by yourself…see sin #2).
LeRoy’s suggestion that you act as the CEO of your project (sin #1) has come into to sharper focus for me recently. I’ve worked on many projects where getting all the details right was more important than getting the project done. I’m not suggesting that buggy or half-baked software should go into your production environment, but PMs should be looking for ways to get working portions of software projects in the hands of the customers as early as possible. In the past few years, I’ve started evangelizing about how a system waiting to go to production provides no value to the organization.
Check out the article. It’s a good read.
NOTE: Projects At Work requires registration to read. This will result in some graymail, but Projects At Work consistently delivers good content to my Inbox as well.
I’m launching the blog with all of the fanfare and pomp reserved for new public-access cable TV shows. If this goes as planned, my first post will pass quietly like the sound of a tree falling in an empty forest. Instead of searching for something profound and meaningful to use as the cornerstone for this little encyclopedia of Keil, I decided to just blurt out something and avoid all of the procrastination normally associated with trying to write the perfect post.
Fortunately, today revealed a pretty good topic for discussion when we extended an offer for a new staff member who is a former co-worker that I’m really excited to work with again. We won’t have his response for a couple of days still, but the incident brings to light something that I think is very important for project managers and those in leadership positions in general: The power of a positive (or hopeful) viewpoint. Three weeks ago, I learned that one of my developers had taken a position with another organization. She was a fantastic contributor on our team and we all knew that she would be tough to replace. It would have been easy at that point to focus on the problem (“great, we’ll never find another Lisa”) and skulk about, projecting that negative attitude on my team.
In my opinion, good leaders regularly find opportunity in the challenges they face. Now I’m aware that some situations have no silver lining and simply require the team to grind out the problem. In most cases, however, opportunities can be found by looking at the issues through the right lens. In our recent situation, the challenge of losing a good team member brought the opportunity to bring on someone who will be even better. Even in those cases where little or no chance for benefit can be seen, remember that a positive outlook that is focused on the end goal will help your team drudge through to a resolution.