As people gain experience, they often want new and different responsibilities. In a typical career ladder (Part 1), they had one direction: up. That often creates a problem: great technical people become insufficient managers. Let’s not blame these people—many of them didn’t want to become managers However, if people want more responsibility, the career ladder […]
Part 1 discussed a typical career ladder. I said that when we focus on individual achievements and deliverables, we ignore the agile system of work. Worse, when we reward individual achievements we prevent an agile culture. That’s because agile teams learn together as they create the product. We need career ladders that reward working together.
As I’ve been speaking about the Modern Management Made Easy books, people ask these questions: We’re pretty good with our agile approach. It’s time for performance reviews. How do we reward someone based on individual work when we want teams to work together? What do we do? Can we extend whatever that is to our
When I think about agile approaches to work, I think about how fast we can change and the cost of those changes. We can change the next decisions about the work because we finish the current work and release it. Multiple deliverables allow us to change what we do and what we plan next. That’s
Michael Mahlberg taught me something cool last week. We’re writing an article together. Part of the article is about forecasts. I was ranting and raving about how to help people see their confidence levels. He pointed me to this slideshare: Lightweight Kanban Metrics (in German). (Don’t worry about the language.) Go to slides 24, 25,
I’ve been working with teams that feel a ton of pressure. On top of the pressure, a senior manager says these words: “Failure is not an option.” When managers say that, they ignore all the possibilities for success. They put their heads down, ignoring ways to manage risk. When managers don’t collaborate to manage risk, we
Several of my clients have intertwined problems. Everyone agrees they want innovation: Which products and services the organization offers. (The project portfolio) What features the product offers, or the problems the product solves. (The product roadmap) In the team, to solve the problems in a way that will attract users/buyers/customers. (The team’s backlog and how
Steve, a software development manager, thought John was a “10x” developer. He explained that John could: Coded faster than anyone else. Write and release full applications over a weekend. “Mind-meld” with the users. No one else in Steve’s group could do this. Was I willing to support and coach the other people in Steve’s group
Part 1 was mostly about unintentional plagiarism. Part 2 was about copyright and when to reference other people’s work. Now, you’re pretty sure someone has used your words. You’re not talking about someone scraping your blog for your posts. You really mean Person A has stolen your words and passed those words off as Person
Many of us writers integrate other people’s ideas. Or, we use those ideas as inspiration for our writing. Can we avoid plagiarism and still acknowledge other people’s work the right way? And, if you can, get “credit” for your “thought leadership?” There’s a lot there to unpack. Let’s start with copyright. Start with Your Copyright As