You are currently browsing the category archive for the ‘Management’ category.

  • Who are your customers?
  • What do they ask you for?
  • What do you do to the requests?
  • And where do they go when you are finished with them?

via What business are you in? | DJA.


I see a lot of CIOs spending a lot of time — which is very important to do — on major business initiatives. But I often see an inadequate amount of time spent where the day-to-day, most frequent touchpoints are, which is with all the other ways the people in the company are their users. One of the big changes that has come with the mass consumerization of technology is that IT needs to flip that around a little and spend more time focusing on the overall employee experience.

from Google’s CIO on How to Make Your IT Department Great .
So happy to see that I’m not alone: before asking to sit at the ‘business table’ , dear CIOs, be sure to know how to do your homework first!
Incidentally this means you should have an IT background 😉

when we look around at the companies who are doing well, it can be hard to see the rhyme or reason of the decisions that led to that success. Take Apple and the work it put into building a technology platform on which hundreds of thousands of independent developers could create apps and offer them to Apple’s customers. Or take and its willingness to have self-organizing development teams continuously tweaking code, even though, with a global system serving more than two million subscribers, the risks of introducing errors into its 30 million lines of code would seem to present compelling reasons not to. (Drawing on the software development practices known as Agile, Scrum, and XP, the teams work in short, iterative cycles of test-driven development with direct customer feedback as the work proceeds.)

In fact, these companies are not behaving chaotically. They are acting according to a rethinking of the rules to suit today’s business conditions, and learning new heuristics based on their successes.

via Making Management as Simple as Frisbee – Steve Denning – Harvard Business Review.


A manager has to know when to ignore a precise number. “He has to know that ‘larger’ and ‘smaller,’ ‘earlier’ and ‘later,’ ‘up’ and ‘down’ are quantitative terms and often more accurate, indeed more rigorous, than any specific figures or range of figures.”

via Fat Chance | The Drucker Exchange | Daily Blog by The Drucker Institute.


In life or death situations, the military needs to make sure that they can shout orders and soldiers will obey them even if the orders are suicidal. That means soldiers need to be programmed to be obedient in a way which is not really all that important for, say, a software company.

In other words, the military uses Command and Control because it’s the only way to get 18 year olds to charge through a minefield, not because they think it’s the best management method for every situation.

In particular, in software development teams where good developers can work anywhere they want, playing soldier is going to get pretty tedious and you’re not really going to keep anyone on your team.

via The Command and Control Management Method – Joel on Software.


We will talk about a new development technique called WDD or Worries Driven Development.
You might know another couple of *DD techniques: TDD and DDD but they are by far less powerful than WDD.

TDD or Test Driven Development has been invented by Ken Beck (@kentbeck). As Wikipedia states “is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test and finally refactors the new code to acceptable standards”.

DDD or Domain Drive Design is a little more recent, especially it’s hype, and as Wikipedia says “is an approach to develop software for complex needs by connecting the implementation to an evolving model.The premise of domain-driven design is the following: Placing the project’s primary focus on the core domain and domain logic; Basing complex designs on a model of the domain; Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.” In Italy Alberto Barndolini (@ziobrando) is really good at it!

WDD is more powerful because it works at a deeper level. It acts at the level of motivations. We tend to do what we do for one of two reasons: to seek pleasure or to avoid pain.
Now our culture tend to push us to the ‘avoid pain’ side so we tend to use it more often as a motivation to do what we do. So what’s more relieving than solving a problem to ‘avoid pain’?
That’s where WDD come from: we do what worries us. Or better we do, schedule, put in priority what can have consequences that can worry us.
So the algorithm is: if you don’t have it, create a problem, throw it in the future, communicate it so that everybody can be worried. Now you are ready to make a lot of overtime to solve it to ‘avoid pain’.

The secret? WDD is not that new: it is quite often used as a primary development paradigm in many offices of medium-big corporations. And it works …. maybe.


I’ve heard, in different moments in time, different definitions of how an IT Manager, a CIO, should look like. Which are the most important skills, the background she has to have.

At the beginning, it was all about technology:

IT was too far from human beings

and IT was available only in big corporations. The IT Manager was the guy with the white coat: an expert of her matter. An IT guy.

Than IT became more commodity and it was the time of business:

IT was too far from the business

and IT decided it was time to talk the language of the business. So the IT dept moved under the CFO or the COO, and the IT Manager became a ‘business man’. Technical skills were no more important for her: there was the outsourcing and the SLAs to cope with the ‘technical stuff’.

Then the internet came, and Google, and Facebook, and Twitter … and all of the sudden

IT, inside corporations, is too far from real life

and people inside the company use to have such a bad IT experience that he would never accept at home … even for free.

To manage all of this we need a new race of IT Managers: they must have deep understanding of both parties. They must know a lot about IT and a lot about making business. But today it’s no more enough. Nowadays IT tech skills and management skills can be an obstacle, sooner or later, if they are not enriched with good design skills.

In the innovation and design era, to move IT at the right speed (maybe 10xFaster) and at the right level of innovation, IT +  management + design have to be carefully used, melted, weighed out.


p.s. Thanks to my friend Nico Bigi for the inspiration of this post

Very interesting talk by Prof. Elena Malaguti during TEDxReggioEmilia .. in Italian

“A lezione di resilienza: Come recuperare dopo un trauma”


Today I read this tweet from @JerryWeinberg

When managers don’t understand the work, they tend to reward the appearance of work (long hours, piles of paper, …)

This reminds me of the risk of setting (wrong) goals.

  • if you are (VERY) lucky, you can just achieve them. No matter how they mach with the overall goals of the company (assuming the goal of the company is clear). No matter how you do it (the more you push on incentives on these goals, the more people will ‘act’ to achieve them .. no matter the consequences);
  • when you set the goal, you alter the ‘system’ in an unpredictable way as people start behaving differently: what if the goals of different people start colliding? And this is even more visible when there are incentives related to these goals.

OK you might say that all these ‘unexpected consequences’ are because ‘they’ are not able to set goals properly: well, as my experience says that setting right goals is impossible, I think that MBOs, SLAs, KPIs tend to ruin organizations more than helping them … and give manager great excuses.

[new] What’s even worst with SLAs is that managers tend not to read contracts properly, and who read them (lawyers?) are not the ones who understand the content.

So this is a system that in theory might work but in reality it doesn’t … because we are humans and not predictable machines controlled in closed-loop.



Need a way to get things done? You should follow the Pomodoro Technique by my friend Francesco (also on twitter).

Look at the new video on Vimeo: it gives a clear (and funny 🙂 ) idea of what the Pomodoro Technique is.

To know more, just go to


p.s. Disclaimer: I receive no compensation of any kind for this post … I just like the technique and I appreciate Francesco 🙂

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 2,738 other followers

Connect with PieG

Certified Scrum Master

Map of Visitors

Anobii – my bookshelf

Here is (part) of my bookshelf and my wish list

Flickr Photos

first light

Winter Wonderland

Fox Sparrow Wintertime Inceville Los Liones Canyon Los Angeles 051

More Photos


%d bloggers like this: