Archive for the ‘Talent Management’ Category

Sometimes things change, and now is one of these times. I will chnage from product management to actually implementing software at real customers.


If we look at my career I have been


  • Developer
  • Systems Architect
  • Presales
  • Done operations
  • Product Management
  • Training


But I have never actually implemented any talent management software at a customer.


Now I will do that.


I will use my knowledge about the processes, about the software and my experience from over 16 years in Talent Management world to help customers make the best use of our software. I will train them, listen to their fears, listen to their expectations and make the best possible project for them that will end in a successful implementation.




Maybe, but I am sure that I can contribute in this part of the talent management world.


That however will lead to that this blog will see fewer posts.


So for more frequent posts head over to my other blog. Http://silofreetalentmanagement.com



Read Full Post »

Saed Khan wrote a series of really good blog posts about the term Product Owner

I agree with most of his writing but have some observations of my own.

  1. It’s all a game of dominance
  2. Please keep in mind Title and Role are different things

Game of dominance

In one of my earlier jobs I worked closely with a department doing payroll systems. Their product manager had come to the conclusion that payroll was all good but he needed to broaden the market and the software. In the same way as ERP vendors are adding modules and functionalities to their software payroll vendors needed to broaden the view and try to take features into the system before ERP did it. Was that because he genuinely thought that all functionalities should be part of the payroll systems? NO, it was all a game of dominance. In the customer software landscape, what software was to be the dominant one, payroll or ERP?

Today we see a movement where everybody tries to be System of record for employee data. Should it be Payroll, ERP, finance or Talent management?  It’s all a game of dominance. What piece of software will be the master piece and set the data model?

And in SCRUM – Product management we have the same.

  • Is it the Developers or the Product management that drives the process and the terminology?
  • Who defines the scope?

So far the development community has been very successful at setting the terminology and defining the roles. But we are now seeing the product management community waking up and saying “wait, we don’t agree”. It has taken some time but finally our community is starting to agree on what we are, and that is the first step in order to be able to tell everyone else what we are.

So as a result we see blog posts about the term Product Owner. That term is a developer driven one and as a product manager I feel it is too small and narrow. I do so much more than just what the product owner is supposed to do. The way to solve that is not by broaden the scope of Product Owner; it is to realize that the title and the role is not the same.

Titles and roles.

So we get to the difference between a title and a role.

  • A title is something you put on the business card
  • A role is something you act in

A Role (Product Owner being one) is often just part of your day.  As a Product Manager (Title) you act in more than one role, and Product Owner might be one. Note that not all Product Owners are Product managers. As a Product Manager you deal with sales, delivery, customers, launches, competitors and more.

So I think that the terminology in itself is not so important. The important thing is that we as a group stand up and say “We are Product managers and being a Product owner is just one part of what we do, the rest is not part of the development defined process”

With a better defined Product Management community we should be able to stand up and set our own terminology and also set what boundaries we act within. We are not to be defined by just one process within our organizations. Sure we will act in different processes and when doing so we will use their terminology, but we must be very clear that we do act in more than one process and in doing so we need to set our own terminology and our own agenda. Making sure we don’t drop Product Manager is just one small but important step in this.

So keep acting in the SCRUM process, keep using the terminology Product Owner (probably too late to change that one), but make sure that the scope creep does not try to define what you do as a Product Manager.

Read Full Post »

I just launched my new talent management blog over at Silo Free Talent Management. That means this blog will in the future be dedicated to Product Management, Agile and SCRUM

Read Full Post »

When I started this blog I decided to blog about 2 things

1. Product management
2. Career and succession planning

They were what I worked with, and still do.

Now I also pick up performance planning as a product manager so it is only natural to widen the scope to include that. I may in the future split the blog to a Talent management blog and a Product management/agile blog. But for now I will keep them together.

I will however make exursions into the other processes in talent management as I strongly believe they are all connected. We are in fact talking about silo free talent management. And that is an area I want to explore further here.

So in the future it will be more talent management coming this way. Both my views as well as book reviews, comments on research I get my hands on and blogging from conferences. (Bersin IMPACT is next up).

So lets explore the future together.

Read Full Post »

Once again away to India. This time for almost 2 weeks with my old team and also take on another team as their product owner leaves for other duties.

It is allways exciting to get new work friends. This time I will meet them for the first time in person to start it off. I am sure it will be great fun. But it is allways a new unknown to be dealt with. One of the reasons is left life in consulting was because of the unknown element in new assignments. Well here we go again:-)

During this stay we have sprint reviews ,retrospectives and plannings. First time in person. Great.

Another item is to work with team and scrum masters on process. So much easier when a discussion about these things are face 2 face.

Lastly there is collaboration with uk based product owner. Just feeling strange to go to Mumbai to work with europeans.

Will get back later with reports. Now off to flight from Heathrow to Mumbai.

Read Full Post »

Another Talent Management book that tries to define what it is and tell us how to work with it. The angle in this book is that you should keep it simple and not add anything to your processes unless the benefit really outweighs the cost.

One page talent management

One page talent management

Well. That sounds like an obvious statement. But if that is a fact why do so many organizations make it so complicated? One reason is probably that it is still far too common to see our TM processes as unique and we really need them as our own business is so different and unique. Well it’s not.

The book goes over the processes for

  • Performance management
  • 360 assessments
  • Talent reviews
  • Succession planning
  • Surveys
  • Competencies

The conclusion is that for each process you should look if you need it. What parts do you need and what data do you need to collect. Don’t collect any data that you don’t know what to do with. Do away with all the “it’s good to have for the future”

What I like with the book is that in every chapter they comment on the most obvious objections you might get from people around you. Off course that is also a way to get you over to the simplistic side of things.

It’s a really good read for a number of reasons. It gives a good overview of Talent management. It gives you tools to implement easy processes and it also might open up your eyes for the fact that you are not unique and you don’t have to be unique.

And the last part opens up the road for using standard software to support your processes without all this overcomplicating adaptations that we are so fond of.



Read Full Post »

When we do succession planning we can use 3 modes.

1.       We plan successors to individual employees (Anna can be a successor to Sven)

2.       We plan successors for positions (Anna can be a successors to all sales managers in Prague)

3.       We plan successors for talent pools (Anna can be a Sales manager)

But where do we start, which mode to use?

It all depends on what you need right now and what your goals are. If you intend to start with Succession planning on your upper level management you probably want to go with option 1. The differences between different positions are so big that they can’t really be connected to pools, and you only have one employee per position.

If you on the other hand just need to make sure you have a pool of talent for all different types of position you will go with the 3rd option. Build your different talent pools and be content that you have successors for all different jobs. You may not really care about their geographical locations as long as you have available successors regardless of the competencies they need.

If the geographical location is of importance you may end up going with the 2nd option. You really want to make sure you have all successors, and you need to make sure you have them everywhere.

So what option should you choose?

Do you have to choose one? Why don’t use a mix of all 3? For you upper level management make it person based, for the rest make it position based, but also keep your talent pools. These can later be combined with career plan data to provide you with who is willing to move and who would be suitable for that expansion into Africa your CEO is planning.

But to make it more interesting. If you have to go with one option, which would it be for you?

Read Full Post »

Older Posts »

%d bloggers like this: