Company Culture is more than words

Or- your culture is more than your developers.

[Disclaimer: This is based on observing the industry and an amalgamation of many peoples past job experiences. It does not represent any one company or person's experiences, past or present. ]

I was doing everything right. My laptop was closed, the projection screen showing a high level status dashboard, as I focused on looking around the room. Pen in hand I was ready to capture actions and issues that came up in the meeting. I was making sure to focus on saying "we" and not "I", asking short questions and not monologing. In short I was being the perfect project manager.

And the meeting was an absolute total failure.

Bob was slumped in his chair, offering monosyllabic responses to questions that he once went on for minutes at a time. Tech Writer, Sue's fingers were unusually still, odd given she usually can put in a 1000 words during a meeting. Even James, the intern was unusually "un-chipper". I'm pretty sure he was doing the Smart Phone prayer and updating Facebook under the table edge, James never used to use tech in the meetings.

"So, Jake" I ask the engineering manager. "Where are we with the plan for how we'll update the web store once we release?"

Jake give a non-committal shrug. "I'm waiting for a response back from IT. "

I blinked, biting back and urge to sound frustrated. What the heck was going on? We were three quarters through the release. Things were going great, no major bugs, issues, risks. Heck the brass had even thrown a 'developer's BBQ' just last week to show their appreciation for all their hard work. Why the hell were they acting like someone had died?

"Someone did," and like a bad stock tip Hogarth was perched on the edge of the table.

Deeply annoyed I said, "now what? Their some of the best paid devs around, they just got a party, the brass just got done talking about how valuable they are. Why are they acting like it’s a funeral?"

"'Cause culture is more than your developers…"

So we're going to talk about a pretty ugly gorilla today. 

Tell me if you have heard this?

  "Our culture is who we are."

  "Investing in all of you, is how we will succeed."

  "Together we win."

  "It is our employees, that make us so strong."

All right, following me so far? I'm sure most of you have sat in a company all-hands and heard something similar to this. Now some companies have done an incredible job converting these words, into reality. Google is famous for its culture, Japanese car companies at one time were the epitome of this. Read Fortune, Fast Company or any other leading business periodical, you'll find showcase articles. Fortune actually devotes an entire issue to it, every year. Oh and it's not a high tech thing either, Fortune's 2009 list had a financial company, a  super market chain and a hospital all in the top ten. One of the things that makes these companies so compelling, is how they create a bond of trust and respect with their employees.

"Yeah sure," mutters Hogarth, "but you don't mean payroll right? We can outsource payroll and save a bundle." Peeling an onion, he takes a big bite. Talking through spray of onion bits he asks, "How about IT? Everyone's cutting IT now. Give a months severance and get 'em out of the way so we can focus on the real company. I mean after all, we don't need them to ship the product, it's the developers that matter, right?"

And the "What is culture" gorilla looms over the discussion.

Some companies have conducted these "streamlinings", "resiliency protections", "austerity measures" and in the process managed to shatter their corporate culture. 

Wikepedia defines corporate culture as,  "The total sum of values , custom, traditions, meanings that make a company unique." That's the total sum, not just the developers or core money makers, but the total sum of the company. 

One would think that we would have learned from the last downturn. The Dot.com crash was just a decade ago, but I look around, not just the high tech industry, but corporate America as a whole and I see the same patterns.  Companies are slicing through their budgets like a drowning man .

 It's a proven fact, that companies that invest in their employees, have more productive and happy employees. They are often noted for their innovation (look again to the example of Google or Apple).  They do not always have the largest market share or the biggest bank roll, but when it comes to people wanting to work there, they have people camping in their lobbies to try and get an interview.  I no longer remember the name of the company, but one of the most striking companies I ever heard about, was in an article in Fortune. It was so compelling, I actually sat there and thought about how I could change industries and move across the country, for a chance to work for this little 400 person company.

I'm not saying companies have to hold onto every employee, never outsource and never change, but they can't believe it won't have an impact on the survivors. Tina Turner sang in one of the Mad Max theme songs "the living will envy the dead." If a company is not careful, they will shatter their culture in the process of surviving. There are dozens of companies in Silicon Valley that probably could have survived, had they been intelligent about 'right sizing'.

So what can you, as the project manager, do? Unfortunately there is little you can do about what a company may or may not do with "right sizing", or how their "austerity measures" upset employee morale.  What you can do is be an even better listener. Spend more time on your Project Management One-on-Ones, your MBWA (management by walking around). Give people a safe outlet to vent and talk. Often that's just what they need. Go crack open 7 Habits and review your empathic listening skills. But remember! You still work for the company. You don't bitch about the changes, you support them and you support your team. You listen and you keep being effective and there.

Joel BC

Veteran, the Project Manager wars

Want me to talk to your gorilla? Send me an email

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

I can see you Gorilla

The program team meeting was progressing. Progressing might be a strong word, maybe it was crawling along like a drunk slug in an ice storm. I looked down at my screen, scrolling through several pages of data in silence before half looking up again. "According to the reports, we have four P1 blockers on the release, Jake what's the status?"

Bob's eyes half flicked up from his computer screen before registering that "John" sounded nothing like "Bob". The two Tech Writers were splitting their attention between a marked up manual and their open Macbooks, while James the intern was sitting up in his seat hand poised over a notepad ready to capture something important.

Jake on the other hand was at the far end of the table head down at this open laptop and fingers screaming away. It seems in the time it took me to find the data I was looking for Jake had decided to recode the entire database architecture.

"You know," Hogarth drawled leaning over my shoulder to look down the table.

I waved off Hogarth without looking up. "Hang on, Hogarth." I tapped furiously at my computer, hitting enter to the satisfying sound of <ping>.

At the far end of the room my computers little voice was answered by a corresponding <ping> emanating from Jake's computer. Jake's fingers paused.

Hogarth looked at me, "You did not just Facebook chat that engineer!?"

I looked up at Hogarth, trying to give him the stare that said 'Do you have two heads, cause you make no sense?'. "Yes, I wanted to make sure I got his attention."

At this point Hogarth made sure he had my attention. <SMACK>

"Ow! What was that for?" I demanded of my gorilla.

"For gross idiocy in the running of your meeting."

"Me?" I exclaimed. "I am not the one rewriting the codebase to the Library of Congress in the middle of the meeting!"

Hogarth gave me 'the look'. The one that told me he thought I'd just said about the stupidest thing in the world.

And he was right…

As the project manager, the way the meeting runs is your responsibility and yours alone. And how you conduct yourself is the first and most important thing you need to focus on.  I don't know if it is a Mark Horstman original, or a re-quote, but he has often been heard to say "When looking for the source of a problem, start by looking in ever increasing circles about yourself."  In other words, the examples you set will be the examples your team follows.

Computers in meetings is a major area of contention. The Manager Tools team make no bones about it, if they are coaching you and you insist on taking a computer to meetings, they'll drop you as a client. Hear that sound? That's the keening wail of protest coming from Silicon Valley. "But I take notes, I have data, I, I,I…" I could go on. Heck I've said most of the excuses myself, and as much as I hate the concept of taking my hands from my precious keyboard, Horstman is right in so many ways. No matter how professional you are, the minute that screen flips up, a small part of everyone's brain assumes you are doing something else. And come on folks, we all have been guilty of doing just that. "Oh well, I'll just check that one email," "Hey look, there's that error in the code," "Ooh, Diane updated her Facebook with photos from last weeks beer bash," and so on.

Now Manager Tools makes a lot of good points and I admit to not being as good as I could be. When I am attending a meeting that someone else is running, I try very hard to leave the laptop at my desk. Taking notes on paper is really much more efficient. Yes it requires you to copy it into the computer later, but you have more flexibility with the MK I pen and you are being more professional and more focused on the meeting, not your technology. Heck, the act of transposing to the computer will lock the meeting in your mind all the more.

The biggest argument I hear to this is "I have information on my computer that I might need". I can't argue with that, but I can argue that you don't need to have your computer open the whole meeting. Need to give an exact answer on the sell through rate of the NewCo Gizmo? Then open your computer, look it up and then close it again.

"What about when I'm running the meeting? I am the project manager." Right you are, but there are rules here as well.

·         If you are not presenting, then close the computer! The reason to have a computer in the meeting is to share data with the whole team. If you are not sharing, then you are shutting out your team with lid of your laptop.

·         If you're not typing, close the lid. Many times the information on the projection screen is just for reference and the main talking happens in the room. Close the lid and engage in the meeting.

·         Take notes on paper. Keep your notebook open and ready, jot your notes in the notebook not on the computer. Update the power point slides after the meeting, not in the meeting. If you're not in presentation mode, something is wrong.  There are some exceptions to this, but very rare and focused mostly on real time updating. Using a MindMap to create a Work Break Down structure? Then type on the computer. Need to note a reminder to schedule a meeting next week to follow up? Put that on your notepad.

A final note on taking notes.  This isn't college, this is work. You are not trying to document everything that was said in the meeting, you are capturing action items, follow ups and critical points. Manager Tools recommends the Cornell Model note taking (Yes, they even have a podcast dedicated to it). I have been using it to good effect for more than a year now.

Joel BC

Veteran, the Project Manager wars

Want me to talk to your gorilla? Send me an email

You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

OpenAgile- The PMs job hunt best friend

"What'cha doin?" Hogarth's question was nonchalant and as innocent as a cat burglar caught hanging from the ceiling.


"Remember when I was out of work last year," I said. "I tried to apply project management discipline to my job hunt, but it just ended up being a revolving to do list. I think if I use OpenAgile, instead of Scrum, we might really be onto something."


Dropping onto the couch next to me, Hogarth pulled out a banana from… Well some mysteries are better left that way. Pealing the banana he asked, "How come?"


I looked over at him, "Well for one thing, it wasn't much of a Scrum team with just myself and my gorilla."


Hogarth sat up, an indignant look  on his face, "Scum?! I'll have you know my father was a silverback for one of the largest bands in the Congo!"


I rolled my eyes, "Not scum, Hogarth, Scrum."


My 900 pound gorilla quickly deflated, "Oh." Looking at me he said "We're not going to France either, are we?"

"No, were not going to France..."

Hello and welcome to a practical Gorilla blog on using the OpenAgile Methodology for conducting a personal job search (For those confused about going to France, or what OpenAgile is, check out my last Blog where I review OpenAgile).

If you haven't checked out OpenAgile yet, it will help to at least have looked at the Process Reference sheet. I've put an image below, but it will help to have the actual PDF. To get a full understanding, go and grab the OpenAgile primer.

I'm going to go back to my own job hunt here. Like many Project Managers, I set out to tackle unemployment like it was a project. A nice a firm start, middle and end (A job). I can't speak for other PMs, but I found that once I rolled up my sleeves and got into the search, I was just working from a task list. I had a loose method going, but I wasn't approaching my search in a manner that allowed flexibility or repeatable structure (yes, you can have both in a project). My search became disjointed and often interrupt driven affair. It turned out well in the end, but I think if I had OpenAgile, things would have gone much different.

A traditional Waterfall methodology really isn't going to work well for running a job search project. A long planning cycle, followed by development before ever getting to Qaulity feedback means you could be applying for a job that was filled two weeks ago.  At the same time, Scrum isn't really the right fit either. Scrum is targeted at a teamwork process, with clear roles and is still very much geared towards a software development cycle. I tried using Scrum for my last job search and found it to have too much unusable overhead (which for you Scrum Masters our there that has to sound funny).

OpenAgile on the other hand has a very open structure, that can be easily adapted to nearly any kind of project (Perhaps OA Exec Direct D. Parker will do a blog someday on how he used OpenAgile to organize his cross country move). Where even Scrum has a Scrummaster, Product Owner, and Team Members, OpenAgile has only the Team Member, with facilitative work of Growth and Process facilitator potentially being all wrapped up in the same person. Almost makes me thing of OA as the zen Agile practice. "There is no spoon, you are growth and process in the same being."

All right!, enough theory, how would I use OA to job hunt?:

Cycle Length: Weekly. You want to be highly responsive during your job hunt, so a week is the best cycle time. Further, a cycle is Monday to Friday. You may be out of work, but weekends shouldn't be scheduled. You need down time and if you have a strong process for job hunting, you can take that down time.

Value Drivers: This is an area little covered by OpenAgile. OA is focused on the execution (which is a good thing) and doesn't currently have a body of knowledge around the generation of the Value Drivers (Scope, Features, "What is Done"). At the high level a VD should be "a characteristic deemed desirable by the stakeholders that is measured in relation to a goal. OA also recommends that Value Drivers use the S.M.A.R.T. goal format.

In the arena of your job hunting, this is where you define what a successful job hunt and job will look like. This is BIG, but is not in the scope of using OA for the actual job hunt. OA is about executing to the Value Drivers. There is a great concept called Value Levers which is used by such big names as Intel. I promise Hogarth and I will talk about it in the future, but email me if you want a copy of a Value Driver presentation I attended this summer.

Stakeholders: A quick note on these. Obviously you are a stakeholder. But your family is also a major stakeholder. Another stakeholder you can't ignore is your bills, more to the point, the people you pay your bills to. Even your poor car can be a stakeholder. Job A is perfect! But it's 60 miles away and your twenty year old Geo Metro isn't going to hold up well for that commute.

Enough on the ground work, now to the execution:

Start at the Circle: So one of OAs key components is the Learning Circle. One of the best things about it, is you can start at any place on the circle. In this case though, we'll start at the beginning (Flip to the second page of the OA Process Reference Document).

Reflection: Time to start with brutal honestly. Or in the parlance of OpenAgile, the foundation of Truthfullness. Before you can move forward, you need to reflect on where you have been. The first couple of weeks, these reflections are hardest as you are going to reflect on the last job you held. Moving forward though, Reflection becomes a look back at the last cycle (week) and what happened. I highly recommend the Manager-Tools Hotwash podcast for conducting reflections. The concept of "What went well" and "Things to Look At", combined with an open brainstorming model are very productive. Do it alone or grab your spouse (Significant other, close friend, etc) or reflect as part of a job hunt networking group.

Learning: I love OpenAgile for this. Lesson Learned (often better known under their more morbid name of "Post Mortem") and even Agile Retrospectives too often combine reflecting and learning into the same step. If you listen to the Hotwash cast, you'll probably understand quickly enough. I think of the Learning phase as the phase where you decide how you will apply the knowledge you gained in reflecting. By separating these two steps, it is like brainstorming . In Reflection, the goal is just to think, to reflect, to write stuff down, not to try and come up with a fix or solution. The Learning phase is where you decide how you will take the Reflections and put them to use. By giving them a space, you separate the emotion from the learning. Instead of kicking yourself for not having any cards to give the guy in the Starbucks line, you "learn" from the experience and set a task to go to Vistaprint and order some cheap cards.

Obviously, I espouse separating Reflection from Learning. Taking a page from Scrum, do your reflecting at the end of the last cycle (Friday afternoon) and do your Learning at the start of the next cyle at the Engagement meeting (Monday morning).

At the end of Learning, you should have some solid tasks, or process improvements that can be incorporated into the next cycle.

Planning: Now here we are again, right at the meat of it all. It's where we Project Managers often commit our worst sins. When we are planning multi-million dollar projects, we do a great job. When we are planning out something for ourselves, we too often get lost in the weeds or fail to plan in depth. The OpenAgile process breaks down planning into five distinct "artifacts". Calendar Events, Obstacles, New Artifacts, Quality Problems, and Repetitive Activities. I can't give this section the attention it fully deserves without all but re-typing large sections of the OpenAgile primer. But let me give a broad sweep on why this is good.

Breaking your activities down into the OA manner allows you to provide greater focus and importance. I like to think of it as a practical application of Covey's Habit 2 Urgent/Important Two by Two grid. It's a way to make sure you are "doing the right things" and not getting lost in the minutia that can be the death of a good job hunt.

Calendar Events: This is just common sense. Peter Drucker spoke of this for decades. If you don't plan your schedule, you won't be effective. What meetings and events do you have? If you don't list them, you don't know when you have open time to work. If you have a task that is best done in one sitting and you think will take eight hours, don't schedule it on a day when you have a networking lunch with old co-workers.  Make sure you schedule time to work on tasks (New Artifacts and Repetitive Tasks). If you know you're best at writing in the moring (you are customizing your resumes to every job right?) , the try to schedule that phone screen after lunch.

Obstacles: Roadblocks, Blockers, Speed Bumbs, we call them many names but in the end they keep us from getting our job done (and when you job is finding a job, that's bad). Remember last cycle, you didn't have a business card to give that guy in the line? That's an obstacle to your being able to easily advertise yourself. Convinced that HR person is blocking you from advancing when you are perfect for the job, that's a potential obstacle.  In Covey speak, Obstacles are Urgent/Important Quadrant 1 activities. Fix them fast, get them out of the way so you can go back to Quadrant 2.

New Artifacts: The heart of your activity cycle. New Artifacts result in the creation of something concrete. "The creation of a document, a process, or a tool, or changing existing documents, processes or tools are all examples of New Artifact tasks." New Artifacts have to be sized (Scrum estimating here we come, planning poker anyone?).  In job hunting terms, these are your resume updates, your cover letters, your contact emails to that old friend working at Amazon. Yes, it seems detailed, but you do need to plan out just who you will be emailing or calling this week. I personally used Mind Manager for this, mapping out each job I planned to pursue, each person I was going to communicate with, etc. I updated it at the start of every week and tweaked it daily.

Quality Problems:  Very similar to Obstacles, only these issues arise during a given cycle. Like Obstacles, they move straight to Covey's Quadrant 1 for immediate action. "Wow, did I really put a resume on Monster that says I am a professional "PiMP"?, gotta fix that right away!"

Repetitive Tasks: Don't be so quick to dismiss this one. New Artifacts are going to be your big fish (Intel is hiring for just your skills, need a plan to attack this opportunity), but to get the big fish, you often need to go dig up the bait first. OpenAgile suggests an RT format of “Every ____ we will _____.” (For example, “Every day we will check voice mail.”). A big part of job hunting is the unsexy, unglamorous practice of checking your sources. It also is a way to take control of your interrupt driven schedul.., (hang on folks I just got an email). Yes, that's right, stop looking at your email every 60 seconds. This harkens back to Drucker and Manager Tools, schedule three times a day to review your email. Make them set times with a start and end. Make them the same time every day. That's repetitive and that's good time management.

A final thought on repetitive tasks, and I know this is going to sound silly, but I speak from experience. Job hunting is a job, give it set hours. In my last job hunt I didn't do this too well. All to often my Wife would come into the home office and remind me "It's 6PM, are you coming to dinner?" A repetitive task can be a simple alarm to remind you to wrap up and end your "job" for the day.

And ACTION! All this blogging and technically we just finished the engagement meeting at the start of the week. Now that you have a plan, time to take action. You've got your tasks on the task board, you've scheduled your calendar and repetitives, you know what the Quadrant 1 obstacles are, now just summon up the courage and get going!

Just remember your progress meetings. With my own personal modification of OpenAgile, I would end the day with reflections. This gives you a night to mull them over, before you tackle the next day. Then, every morning start your day with your progress meeting. Hit the learning circle and figure out how to learn from your reflections and then look at how you want to change your day. Another great thing about OpenAgile, over Scrum. There is nothing to keep you reaching deep into the backlog, mid-cycle and pulling some task up to the top of the list. Talk about flexibility!

That's it! Yes, there is a lot more to it, but like OpenAgile itself, this is a framework.  A loose  framework to wrap around your own working style. There's a lot you can delve into, a lot you could tweak, a lot you could challenge. So with that, I'll give you one of the last gems of OpenAgile. JUST START! Don't over plan, don't over think, get going and keep going!

Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.

OpenAgile, not just another bad gorilla joke.

It is probably fortunate Hogarth eats so many bananas. The smell of them makes it nearly impossible for him to sneak up on me. And if you've never had a 900 pound gorilla sneak up on you, you've never had a project go from green to all hands on deck in a matter of hours. But I digress.


"What'r you doing?" Hogarth asked around a double mouthful of bananas.


"Reading about OpenAgile" I said, not looking up from the small booklet.


Hogarth flopped onto my desk, "Oh man, are we going to Open Agile this year? I always wanted to see eastern France!"


I sighed, good gorillas are so hard to find. Looking up I fixed my black furred friend with an annoyed glance. "Not Agile Open the conference, Hogarth. OpenAgile the methodology."


"We're not going to France?"


I shook my head, "No, we're not going to France."


My gorilla sulked away, leaving me to ponder his understandable confusion and one of the newest Agile methodologies gaining traction in Agile and Project Management communities.


I had my first exposure to OpenAgile only a few months ago. OpenAgile's executive director, David Parker, had just moved from back East to the Bay Area and local Agile champion Agile Learning Labs hosted an evening informational session. Over good pizza and way to many caffeinated sodas around twenty project managers and agilistas were exposed to the foundational roots of OpenAgile. Just before Christmas I then had an opportunity to take the OA Team Member training from David and OA co-founder Garry Berteig.

So what is OpenAgile and why did I take two days from the year end madness of work to go to this training? Well the latter question is the easier one to answer. As I talk about in the "Every project is a screwdriver", I would rather have a low cost toolbox with a wide assortment of tools, than a single super, high quality screwdriver. I am always in pursuit of new tools to add to my project manager toolbox and OpenAgile looked to be a whole socket wrench set worth of tools.

So what is OpenAgile? Well if you go to their website (http://www.OpenAgile.com). Their current mission statement reads.

"OpenAgile's mission is to continuously bring the best of Agile methods & teamwork beyond Software Development".

Frankly I think the mission statement does it a disservice. Yes, Agile started in the software development space, but it is can be so much more than that and if you tie the anchor of software dev around your neck proclaiming "we're not for software dev!" you might have folks saying "Methinks he doth protest to much." Translation, folks may not give you a second look, thinking you won't work for them. The mission statement assumes you know what the "best of Agile" is, which won't get you many converts outside of Agile. Which is a shame, because I think OpenAgile has a lot of potential.

When I had to describe it to someone, I opted to describe it as "A simple, but highly expandable, open framework for managing any kind of project." Short, simple, and I think very descriptive. What I've liked about Agile, as a whole, is its focus on customer needs (your stakeholders), managing and embracing change (change management), and it's over whelming drive to always ask "Why?" I've seen too many projects fail because of bad inertia. Things get moving and no one raises up their head to make sure they are going in the right direction.

But classic Agile is still very software focused. The manifesto if called "Manifesto for Agile Software Development" and one of the core principles is "Working software over comprehensive documentation." Kind of makes it hard to sell to a hardware manufacturing house, now doesn't it? Scrum is an excellent methodology, I use my own CSM training extensively in my day to day work for a major manufacturing company. But it was built originally for software and while flexible and adapting has limitations that make it hard to use in many types of business.

OpenAgile took an alternative approach to the still adapting Scrum models and stripped everything back to the start and then began building up again. In the process it drew in concepts from outside the 'traditional' Agile approach and tackled the problem from the team first and the project/product absolute second. With the three core foundations of "Truthfulness", "Consultative Decision Making", and the "Learning Circle" OpenAgile has a strong focus on how the team functions. The Learning Circle takes the Scrum retrospective a step further, tying the end of the cycle firmly back to the beginning and really showing how a "cycle" can not only start at any stage (which is great considering how often project managers get assigned to projects already under way) but feeds back on itself to ensure what you learn is applied to what you do.

Now with the praise I have to talk about the other side of the coin. I think OpenAgile has a lot of potential, but it is still young even as Agile methodologies go. It's got a strong foundation in their iterative cycle model (Sprints for you Scrum types), but I feel it is still missing some depth that will come from more use, development and feedback. If people dig into it, use it, and grow it then it could become the next main stream project management methodology. If it fails to gain traction, fails to evolve, fails to grow, it will be a nice talking points concept but very difficult to put into practice.

OpenAgile has a pretty daunting uphill road to climb to become the next Scrum or Waterfall, but one of the biggest things it has going for it is the "Open" part of its name. Like true Opensource, OA is open to modification and adaptation, all of which can and does find its way back into the "main branch" of the methodology. If people use it, it will become better.

It may not yet be a full 50 piece socket wrench set, but I'd definitely rate it as a full set of screwdrivers.

Joel BC
Veteran, the Project Manager wars
Want me to talk to your gorilla? Send me an email
You can follow me on twitter, @JBC_PMP

Who is Hogarth? Read Blog 001 to find out all about my personal gorilla.