Intel CEO Brian Krzanich did an interview which is worth either a full read or listen on the podcast. The part that grabbed me is Krzanich’s take on who you should fire and why.
‘I’ve had to terminate or fire more people for being difficult to work with than being dumb.’
The story resonates as he was almost fired early in his career for what I could see as a dumb mistake. We all have made those and some where not lucky enough to have a boss like Krzanich who understands the difference between making a mistake trying to improve the business somehow and just screwing up.
‘I think if you don’t give people the tools and the expectations for success, and yet hold them to some value, then you’re difficult to work with.’
In my career I have had bosses give me what seemed like crazy tasks and/or timetables, but they let me pick who I could work with and how to get it done which kept me motivated and more often than not I was successful. Partly because I had a good amount of control, but mostly because I had a boss who believed more in me and the team then I did holding us to their expectation.
Look for these type of bosses (more leader than manager) and to become that type of boss.
I owe this rule to my time at 3M.
Their culture of innovation was based on several things, but the one that resonated with me was how conceptual failures by 3M’s engineering and science areas (so-called bad ideas) were not tossed away.
Of course there is the famous Post It Note story.
There are many more were an idea that was first, second or even longer a failure. But, thanks to good process of documenting the idea and the failures, with the most important part of having the ‘failure’ reviewed occasionally to give it another shot.
The innovative companies understand that you should never give up on any idea.
Some ideas are just not ready due to –
- the organization is not ready for that large a leap
- the technology is not available to make it a reality
- the solution to make it successful is not present
Regardless of your organizations industry or role, you can have it be highly innovative, by being fostering an atmosphere of tolerating failure and reviewing your failures for future successes.
The more innovative you want to be the higher level of failure you need to be able to tolerate.
Author Larry Bossidy & Ram Charan
A quick read with each chapter giving you something useful to put into practice. All too often leaders get frustrated that completion of activities is not occurring and they lash out at their teams.
I have been guilty of this action and thankfully my teams have been forthright enough to point out that I was acting like a crazed Captain Kirk asking to get 110% and to just make it so (ok that is Picard).
– Seven essentials of execution on page 57
- While these are built upon in the rest of the book, reminding myself quickly brings back the concepts to actually use.
– As a leader you have to show up on page 63
- Showing up defined as being present, not losing your attention by focusing on your smartphone, tablet or SQUIRREL!
- Focus on the person or people in front of you.
– New EDS Beliefs on page 91
- Changing not the values in your business, department or team – but changing the beliefs about those values.
- First as part of your SWOT identify the old beliefs both internal and external, and then define the new.
– Leadership Assessment Summary on page 151
- A simple chart to evaluate the potential and current value of your team
– Principle of simultaneity on page 232
- During planning session and budget development change from doing separately and start with a gathering all business leaders to set the foundation for simultaneously agreeing to direction, plans and budget allocations.
I review this book once a month to refocus my efforts when working with teams. It offers simple reminders on focusing on priorities and facilitating the same with your teams.
Author Ken Pugh
Picked this book up to add to my LEAN and Agile knowledge. A tough read as it is very reference
based, so plan on taking your time and re-reading several portions of it, especially if you do not have
experience with LEAN or Agile before. It is effective in showing how the two methodologies can work
together and are aligned in their thinking on empowered teams and facilitating managers.
– Manifesto for Agile Software Development page xxxi
- The principles are the focus on this page, like any list of things (aka 7 Habits – I like 4 of them), you should read through the book and come back to this page in integrate into your lean/agile process what will most benefit you. Unless you have a scrum master, then they will beat you until you bleed to follow all of them.
– Questions to ask you and your organization on page 23
- Of this short list, the most important is ‘What are impediments to smaller, more frequent deliveries in your organization?”
- Why do so many projects/initiatives focus on the big bang deliverable at the GO LIVE, instead of 10 smaller go lives that reduce risk, improve success of hitting each go live and remove stress from the humans in the effort.
– Resource map of all projects on page 47 (too ugly to post a picture of so here is a nice picture of a frog)
- Yes, have either a PM or a project coordinator generate these maps, then spend 2-4 hours every two weeks updating them to keep them fresh and relevant, which works well for a consulting firm with a PMO.
- If you are a company looking to embrace agile, well you likely do not have the bandwidth to do this effort. I suggest in place to focus each team member on 3 priorities that are directly tied to the corporate strategy and focus weekly on activities that are impeding work on those 3 each day/week.
– Model of Lean-Agile Software on page 237
- I know skipped a whole heck of a lot of pages, but if you know about LEAN, Agile, Scrum and so forth those pages are refresher and connecting the methodologies.
- The chart at the bottom of the page is simple, but take note of the size of the boxes as I relate the amount of time you should take in training and adopting efforts for each of those boxes. Thus the most time on setting a good foundation of understanding and building acceptance.
I use this to tie my training and experience in project management, LEAN, and Agile together. Is it something I use often, no I will not. But, it will be something I look at when I begin a new project that is either LEAN or Agile or both.
I love these questions for a few reasons.
- They are great to mix into interviews to see how people respond, react and lastly answer
- I re-ask myself these several times a year and especially before I am interviewing or starting a new project
- Use them when I am working with a new team to help me identify their focus
1. What has been the most effective motivator for you to do your best work ever?
2. What work has been the most difficult for you to delegate to others?
3. How would you define the purpose or goal of your work?
4. How have you tried to achieve excellence in the work you do?
5. Of which one of your failures are you most proud?
6. And which of your successes was completely undeserved?
Perhaps I will add my answers sometime in the future.
After x number of years with formal project methodologies, project software tools and training upon training upon training, companies continue to struggle to manage projects. Combined with this struggle is a culture that has a strong aversion to failure (aka risk). I put forth that these two are deeply tied. A business will not improve their project success through a new methodology, new tracking tool, additional training or even replacing the staff with new, more highly skilled staff.
What will improve project success is aggressively killing projects that are not succeeding. Call them challenged, failing, behind schedule, in the yellow or red. If they have missed more than one milestone, they are a candidate to be killed. These projects need to be put under a microscope and examined for the likelihood they will hit their next milestone. If the intense review finds that the project will not be able to meet the next milestone it should be killed. But, remember killing it does not mean you skip the closure phase. Close out the project capturing all the necessary learns and put the resources onto the projects that are succeeding to optimize their chance for success.
Making people work on projects that are failing, increases the pressure to succeed, but does not provide the environment for success to occur. Fail to kill projects and you are begging to be lied to by your project teams. Aggressively killing failed project, completing the closure phase and placing people on projects that are succeeding demonstrates you walk the talk of project methodology and that mistakes are acceptable.
The benefit of an aggressive killing of projects has the positive impact to the bottom line through increase success of other projects and cost avoidance from continuing projects that will fail. Add to this benefit the cultural impact. A fear of failure not only adds stress to a project that is already struggling, but it also creates an overall environment that stifles innovation. People will resist proposing new ideas unless they are guaranteed to have success. How many projects are guaranteed to be successful?
Therefore, aggressively killing projects impacts that bottom line through costs savings and the top line through supporting an environment of innovation by removing the fear of failure. If you find these thoughts on project management helpful and would like to not only learn about solid project management, but not have to read boring project management book to learn it, read The Deadline by Tom DeMarco. Gives you a understanding of good project management but in a fun to read novel format.