Jason Fried, Founder and CEO of Basecamp, recently wrote about how easy it is to be a bad manager. (If you haven’t read it, I highly recommend you do. Managers will recognize their own experiences in his writing. If you’re planning to become a manager, it’ll give you a heads-up on what to look forward to. Spoiler alert: No matter how good you were at your previous job, as a manager you will be a beginner again!)
Fried notes that professional managers have typically spent most of their career doing something else and get promoted to management. In management, they have brand-new, complex situations to figure out. They also have to learn the enigma known as “people” and get good at knowing people react to situations they face. Fried’s summary of the “new manager” experience is accurate: “When you practice being a manager, you’re already on stage. Your flubs have consequences. Fucking up could cost you or someone else their job. It could cost a business money, customers, reputation.”
I shared Fried’s article with my team members, which led one of them to wonder: If you’re learning as you go as a new manager, and your mistakes could have big consequences like costing you or someone else their job…how do you prevent big mistakes (or at least catch them quickly)? How do you ensure your learning curve as a new manager doesn’t cost anyone a job?
Work expands to fill all time available for its completion
I’ve been thinking lately about time and deadlines. Do any of these sound familiar?
You go to a meeting scheduled for an hour. A project decision is made in the first fifteen minutes, and the next forty-five minutes are spent discussing and re-hashing that decision…only to then settle on the original decision.
Your software team works in two week sprints yet seems to scramble in the last several days of each sprint to finish the bulk of the work.
In a project with a deadline months away, the requested feature list continues to change and grow while the deadline remains the same.
These examples are all instances of Parkinson’s Law: “work expands so as to fill the time available for its completion.” Read more
At the last Indianapolis “Leadership Rules!” meetup, we had some great discussions on celebrating wins and rethinking failures. I realized how infrequently my team actually celebrates our wins. We tend to hold off on celebrating while we work toward the end of the project, only to then just slide into our next project. When considering how my team handles failures, I recognized that my team doesn’t always acknowledge the lessons learned from any stumbling blocks we hit.
This is final part of my two-part series that explores barriers to organizational change. (Read Part 1 here.) The examples I highlight were observed in the 1980s when GM tried to transition their manufacturing plants to the Japanese manufacturing process. Yet, these qualities can also be seen in companies today that resist organizational transformation.
The episode of This American Life on NUMMI explored the transformation of the GM Fremont plant to the Japanese manufacturing concept in the early 1980s. (I wrote about it in my article “Bad employees or bad system? Ask 1984 GM.”) The team-based, collaborative concept helped GM build high-quality cars at NUMMI. Yet, the barriers to change in the massive GM organization prevented the manufacturing plant transformation from taking place throughout the company quickly.
The first four “barriers to change” were covered in my previous blog post. Read on for my next three observations about companies resistant to change…and to learn the silver lining about organizational change observed at 1980s GM. Read more
This is Part 1 of a two-part series that explores barriers to organizational change. The examples I highlight were observed in the 1980s when GM tried to transition their manufacturing plants to the Japanese manufacturing process. Yet, these qualities can also be seen in companies today that resist organizational transformation. Read the final part of the series here.
My last post “Bad employees or bad system? Ask 1984 GM.” discussed the employee transformation that took place in the ‘80s when GM and Toyota created a joint partnership to manufacture small cars. Toyota trained GM’s workforce in the Toyota manufacturing process, which emphasized teamwork and collaboration. They opened the NUMMI manufacturing plant together using this method in 1984.
Despite using most of the same employees from the troubled (and eventually closed) GM Fremont plant, the problems that plagued GM Fremont were absent at the NUMMI plant. Workers helped each other. They fixed problems rather than accept them (even when that meant stopping production to do so). People became proud of their jobs and of what they were making. (The story of this transformation was told on This American Life. It’s a great listen.)
Yet, it wasn’t all sunshine and rainbows. Read more
In July 2015, public radio show This American Life aired an update of a 2010 episode on NUMMI, an auto manufacturing joint venture between GM and Toyota in Fremont, California. This partnership was revolutionary in that it brought the Japanese automotive manufacturing system, which stressed teamwork and continuous improvement, to American auto workers. It was responsible for a cultural transformation in the workers at the GM plant that brought with it an abrupt improvement in quality and team morale.
The story of the NUMMI plant highlights how true teamwork can revolutionize a workforce and its output. The experience of NUMMI is also similar to transforming a software development team or an organization to embrace Agile methodologies. (Others have also noticed the parallels with agile software development. See the article “An Agile Transformation Story from 1984” from Matt Block, an Agile Coach also in Indianapolis.)
See if you notice any parallels between your current workplace culture and the culture at GM Fremont plant before it transformed to the NUMMI plant.Read more
I took a road trip to Cincinnati, and I learned a lesson about Agile software development from a decoration in my Airbnb host’s bathroom! She had made this sign and posted it on the wall. Without any context, I read it and thought, “This is how we’re supposed to be building software!” Read more
After my team spent a significant amount of time working on a project, it got halted. Ouch.
It kinda sucked, but it also gave us an opportunity to start anew. We could put the baggage of our old project behind us and start our new project with a clean slate. As a leader, you must recognize that emotions (including your own) must be considered before the team can effectively move on to their next project. We’re only human.
Here’s a plan for handling a mothballed project with your team:
Communicate: what happened and what’s next.
Recognize and recover from burnout.
Do a project retrospective to learn from past project mistakes.
One of my favorite aspects of being a manager is coaching my employees to reach some of their big goals. I like learning about what motivates an employee and what their ambitions are. As a manager, I consider it my job to my employees to remove obstacles, push them when needed, and provide them with opportunities to reach their goals.
I have a postcard of Pot-Shots #571 by Ashleigh Brilliant hanging at my desk: “One possible reason why things aren’t going according to plan is that there never was a plan.” Working with a plan to hit goals doesn’t have to be overly cumbersome and complicated. Here is a strategy I use to drive my 1-on-1s with employees to help them identify their goals and take small steps regularly to reach them. Read more