Tag Archives: Team

Team structure, management & dynamics.

Corporate Cultures

It is said that Netflix represents the new I.T. corporation well.


If you are interested in seeing what their corporate culture looks like, have a look a the slide deck they show to their job candidates.

It has all the flair of the typical Silicon Valley shop with their “we know better than those bunch of twits” attitude, but their critics and response to “normal” corporation’s values is a good read.


But if you want something even more drastic, check-out Valve’s.  Valve Corporation (Video Game distributor, e.g. Half-Life) implements a drastic departure from normal corporation, a flat organization.  Their employee manual has an even more pamphlet feel to it.


In the same vein but in a Brazilian company not related to IT, a good watch is the following TED Talk Video.  Semco CEO Ricardo Semler gives a very inspiring talk about how he deconstructed the “boarding school” aspects of his company, by removing arrival time, desk location, even salary, out of management hands with apparently great success:  his company’s revenue grew many folds under his lead.




Team IQ


I’m still catching up on the articles I read months ago and wanted to share with you!

This one has been published in the New York Times and is about the intelligence of a team or the team IQ.  It asks why some teams are smarter than others?

It starts by stating two fundamental truths most of us know:

  1. In the workplace (and elsewhere) today, most decisions are taken by a group of people rather than individual.
  2. A lot of teams are dysfunctional or at least feel sub-optimal to most of their members

The authors studied a specific attribute of a team, its intelligence, its cognitive ability.  They published studies (from the famous Carnegie Mellon University and M.I.T.) where they compared different teams and tried to see what, in its team members, influence a team collective intelligence.

IQ[1]Surprisingly, it isn’t the sum of the members I.Q.!

Instead, three characteristics had the highest correlation factor:

  1. Each team member contributed more equally to the team discussion (as opposed to having 1 or 2 strong voices and the rest following)
  2. Team members scored high on the “Reading the Mind in the Eyes” test (more on that below)
  3. Team had more women

So the “Reading the Mind in the Eyes” test is about the ability to read complex emotions from the eyes of individuals.  It is also called social intelligence.  You can pass the test here!

The interesting bit about the women element is that it isn’t about diversity (i.e. having a well balanced men-women team) but about having more women onboard!  There is a strong correlation between the 2nd and 3rd characteristic because apparently women score, in average, higher on the “Reading the Mind in the Eyes”.  Although, as another revelation of the study, emotion reading is as important for online / virtual teams as for face-to-face one.  So it isn’t just about reading faces but reading and understanding emotions in general.

As you can tell by my blog site’s title, I work in I.T. and this is where the scientific aspect of the article (i.e. the study involving multiple teams) was key.  Because…  I seldomly experiment teams with women!  You see, I.T. has the same concentration of women by squared meters than a tavern 😉

So there you go.  If you want your team to be cleverer, add women into it.  And for those who are frustrated about the space women take in the workplace, well, keep frustrating because they really bring something to the table and therefore aren’t going anywhere 😉

Large Projects

There is something about large projects that you’ll never find, hence never learn, in smaller projects. The complexity, both technical and in terms of people dynamics, creates an all new set of challenges.

I read the article I Survived an ERP Implementation – Top 10 Gems of Advice I Learned the Hard Way at the beginning of the week. I was interested by the title since although I often work in companies where the ERP occupies a central place (don’t they always?), I’ve never been part of the implementation of an ERP.

As I read the article though I found much similarities between what the author was saying about the dynamics of an ERP implementation and large projects I’ve been on.

I therefore recommend it even if you don’t plan implementing an ERP anytime soon 😉

For instance, here are comments I would throw on the top of my head for some of her gems around ERP that apply to large projects in general:

10. Don’t be fooled by the system sales team. If they tell you “of course our system can do that” or “absolutely, with small modifications”, have your technical experts talk to their technical experts. Go in with eyes wide open.


Overselling a product isn’t a monopoly of the ERP sub industry, unfortunately!

Any complex product can easily be oversold by sampling the feature sheet of said product and matching it with a project’s requirement. The devil often is in the detail and on a large project, you can’t dive into all little details straight from the beginning.

If you are the technical expert or the one assigned to evaluate a product here are a couple of tips:

  • Ask questions, lots of questions
  • You won’t be able to cover everything so try to do horizontal and vertical sweeps: walkthrough an entire business process, look at an entire slice of data, look at an end-to-end identity journey, etc.

9. Whatever time period (and budget) you think will be required to go-live, you are most likely underestimating it. It’s tough enough to be immersed in an implementation, but continually pushing back the go-live date is deflating to the entire organization.


Large projects take more time than small projects, right? 😉 Well, no, they take even longer!

Large projects have explicit steps that are implicit or much smaller scale on smaller projects: data migration, change management, business process optimization, user experience, etc. . Each take a life of its own and shouldn’t be underestimated.

8. There is no possible way you can over-communicate. Regardless of forum, of timeliness, of method, there is no such thing as too much.


Large projects have more people involved and last longer, hence give time for staff to churn. Your message will get distorted through layers of team, time, etc. . So repeating your message ensure that pieces of it will reach their destination.

6. Data is sexy. Learn to love it; treat it with respect and care. It’s the backbone of a successful implementation. You don’t want to to experience go-live with a broken back.




5. A lack of change management will bite you in the butt. Post go-live, the speed at which you get through the hangover period will be heavily dependent on how well you managed change throughout the project.


You think the finish line is the delivery of the project? No, it’s the user acceptance of a new product, the large user base. If they reject it, whatever you have done won’t matter.


1. ERP implementations are equal parts politics and emotions. Ignore the effect of either of these at your own peril.


Expectations, perceptions, unspoken assumptions… ghosts that can harm you as much as the real thing. Do not ignore them!

Agile Trade-offs

It was very refreshing to read Paul Dolman-Darrall’s article about the trade-offs to adopt in an agile delivery model.

Agile is more than 10 years old but still have whimsical attributes of a brand new artefact.  I believe this isn’t unique to agile but tend to be the case for any delivery methodology.  It seems that however how long a methodology has been around, only a limited set of characteristics is remembered, barely understood and cited ad nauseam.

PMI?  Large project plan, rigid schedule.

Agile?  Stand up meetings, open bar (no scope keeping).

RUP?  Lots of deliverables, configurable.


Now Paul’s article dived beneath the surface, exploring different ways to use an agile methodology depending on what we want to optimize.  His analogy with athletes, body type and training is quite good:  e.g. a sprinter doesn’t train the same way as an ultra-marathoner, although both might be world-class athlete.  Also, trade-offs are part of success recipes:  no athlete can excel in both long & short distance.

This graph of his is especially good at expressing the idea of trade-offs in delivery:


What do you need to optimize in your project?

I encourage you to read Paul’s article.

Solution Skill Quadrants–Part II, Solution Architecture

In the last blog post I introduced my own patented Solution Skill model:


I won’t repeat the content of the last blog post, that’s what hyperlinks are for.  The goal of this post is to address this simple question:  as a Solution Architect, how can you help the situation?

Well, your main goal should be to avoid creating solutions generating a lot of fourth-quadrant jobs.  What are those jobs anyway?  I use to work at a place filled with those jobs.  Fortunately, mine was closer to the third quadrant, but most people I managed or interacted with were in the fourth quadrant spewing against their faith.  This is where I created that model in my head!

Basically, a fourth quadrant job is something super complicated and super boring to do.  Examples:

  • Doing a lot of file copies with some complicated patterns (e.g. those 2 files goes in here, those other 3 goes in there, but you must rename them with a timestamp, etc.) .  A typical example is manual deployment.
  • Every time you want to support a new customer, you need to create an XSLT to transform a neutral XML into a branded HTML.  XSLT is complicated.  Evil complicated.  It should only be used to power rocket ships, not as a standard part of a business process.
  • You have a B2B solution relying on some duct taped integration where a file is dropped into an FTP site, caught by a BizTalk Server, some messages are sent to MSMQ, un-queued by a Windows Service with funky credential settings and pushed to an internal web service.  That was super cool on paper, except that in operation, that sucks because the FTP site goes down, the MSMQ gets poisoned, the Windows Services is unable to start once in a while, your Web Service is flaky and there is this SQL job running once in a while that causes delay that breaks other parts.  So…  you have a poor dude somewhere who needs to understand all this technological task and probe around to find the problem of the day when customers or accounting start screaming at him.
  • The solution has a superbly layered design.  I mean it has a lot of layers!  Each layer has a small responsibility.  So there are 8 layers forwarding each other some piece of information in different form.  The problem is that every time you want to add some capability to that solution, you need to create 8 interfaces, 8 implementation classes, 7 custom constructors, override 6 methods, etc.  .  Same thing when you want to change a bit your data representation.  The girl doing that needs to understand the subtlety of each layer, class, factory, strategy, etc. so she can copy files around and rename classes / variables for 2 hours.
  • etc.

Recognised a pattern?  Boring job requiring a degree to perform.  But more specifically:

  • Non-automated repetitive work (manual deployment)
  • A complicated technology used to do what a simpler technology could do (XSLT vs HTML)
  • Too many sub-systems interacting in a brittle way (duct taped integration)
  • Abstraction and decoupling thrown at the end-consumer’s face instead of buried in the foundation of an application (e.g. too many layers, ceremony to create something)

Basically, complexity surfaced at the wrong level.

Your job as a Solution Architect, in order to address maintainability, is to ensure that what doesn’t need to be complex isn’t, even if it means not using 3 new techs and 5 patterns at the same time.  It also is to ensure that what needs to be complex, because it express something complex in the business logic / process, is positioned at the right level in your architecture, mostly, buried somewhere you do not need to touch everyday, so you can send your 3rd quadrant ninja dude look it up every blue moon.

There isn’t any recipe, but what helps me is to think about how the solution is going to be maintained.  Nowadays, we more often than not replace an existing system, so it’s easy to ask around in order to know what type of change requests the old system got and what type of staff handled those tasks.  Imagine them and figure out how many technologies they have to be comfortable with in order to do perform those tasks and optimize.

Solution Skill Quadrants–Part I, the model

For quite a while I’ve been having a model of skill requirements in my head.  That model guided me to analyse situations in different companies, mostly the staffing patterns for the maintenance of applications.  I wanted to formalize it a little more and hence this post.

I call this model the Solution Skill Quadrants.  Now you might ask what this HR digression is doing on a technical blog?  Well, read on, because on top of allowing one to easily analyse staffing requirements and team dynamic, it is also a wonderful tool to influence a solution.

You know, buried somewhere in those non-functional requirements is the ‘maintainability’ one.  This requirements dictates that the solution you are architecting / designing should be easy to change, evolve, maintain.  Easy?  Cheap.  Your solution should be cheap to maintain.  How do I know that?  Well, read on, here’s the model.

Like everything in pop-psychology, we split the world along two axis, in four quadrants.  It’s mandatory, I didn’t create the universe, it’s just like that.

The horizontal axis is the ‘Required skills’ axis.  How much skills does it take to get your architecture, to understand it to the point of being able to make it evolve without accidently breaking it?  This dictates the staff profile your customer needs to hire in order to maintain your solution.  At the low-end of this axis you have low-skilled employees.  Those people are easy to find and do not ask for a Rolls Royce just to come to the interview.  At the high-end of that axis are the high-skill workers.  Scarce on the market, they take longer to recruit and ask for more.



The vertical axis is the ‘Task Challenge / Creativity’ axis.  This tells us about the typical tasks somebody has to perform given the architecture.  At the low-end of the axis, the task are easy, predictable & repetitive.  At the high-end of the axis are the tasks that are uncommon, challenging and require some creativity.

Let’s look at the impact of the tasks on the staff profiles by running around the quadrants:




Here you have a low-skilled employee doing repetitive work. This is quite easy to manage. Actually, the management science was invented and optimized in order to handle that context. If they get bored you promote them if you can, replace them if you should.


Here your low-skilled employee is doing non-repetitive work. The work doesn’t require more skills, it’s just less mundane. Most people enjoy this. The employee enjoys this because he’s challenged within the boundary of his skills. The manager likes it, because his employees aren’t complaining about the routine all the time. Since here you still have a large population of prospects that can fulfill the tasks, you can easily find employees to do the job and you’ll have a good sales pitch for the position.


Here you need an highly skilled employee and you let him go nuts to do ‘his thing’. Typically that person is hard to find and expensive, but the job is challenging for him / her, so they should enjoy it and strive in it. On the other hand, the minute they don’t enjoy it, they’ll have a hard time being understood by their manager who typically doesn’t understand the details of his / her daily job. That can be a challenge.  As an architect, you probably live in this quadrant.


Here you need an highly skilled employee in order to perform mundane tasks. This is hell. You’ll have a hard time finding those employees and they’ll quit on you on a regular basis because the job is boring in general and especially boring for them because they would much prefer to do the ninja job your competitor is opening this month. On top of that, chances are the manager is unable to properly structure the work for that person since he doesn’t fully understand the ins and outs of this complicated job position. Brace yourself, you’re up for some serious turnover of expensive staff who take a while to understand the complicated tasks and resigned short afterwards.
    What can you do as an Architect to help the situation?  This will be for the next blog post!