How  to  Transform  an  IT  Department  Without  Firing  Anyone  I   am   a   huge   believer   that   individuals   are   rarely   to   blame   for   the  malaise   that   commonly   affects   IT   departments.     Instead   I  believe   that   a   dysfunctional   culture   is   brought   on   accidentally   by   mismanagement   who   are   simply   not   aware   of   (or   not  prepared  for)  the  needs  of  technology  resources   in  a  fast-­‐paced  and  ever-­‐changing  environment.    The  people  are  rarely  bad,  the  process  and  environment  and  culture  is  simply  unhealthy,  and  employees  will  act  out  in  many  different  destructive  ways  as  symptoms  of   a   larger   causal   set   of   problems.     The   goal   is   not   to   simply   purge   every   two   years   until   you   accidentally   find   a  successful   group   of   people,   rather   the   goal   should   be   to   retrain   the   management   team,   reset   the   environment   for   the  stakeholders,  and  then  restore  the  faith  and  motivation  of  your  technologists.  

Humility,  Diligence  and  Honesty  These  three  core  virtues  are  what  I  call  the  “untrainables.”    As  technology  teams  are  evaluated,  the  members  should  be  sorted  by  these  virtues  which  can  serve  as  a   litmus  test  of  who  to  allow  into  your   initial  candidate  list  for  a  transformed  technology  team.     Skills,   programming   languages,   and   software   systems   can   all   be   trained   but   Pride,   Laziness,   and   Dishonesty   is   very  difficult  to  weed  out.    I  recommend  isolating  these  bad  apples  early  in  the  process  until  you  can  restore  a  healthy  environment  with  those  remaining.  

Put  Recalcitrant  Employees  in  Storage  (Temporarily)  Unfortunately   the  very   first   step   to   reforming  your   IT   group   is   to  provide  a   safe  and   fertile   landscape  where   the  productive  employees  can  take  root  and  thrive.    This  means  clearing  the  rocks  out  of  the  ground  for  a  bit  (those  stubborn  to  change).    Note  that  I  mentioned  that  they  needed  to  be  put  in  storage.    These  people  that  are  resistant  to  change  generally  have  reasons  for  their  positions.     They   likely   still   retain   some  political   power  and   they   likely  have  deep  wisdom  and   skills   earned  over   a   long  period   of   time   that   make   them   holders   of   institutional   knowledge   and   situational   business   awareness.     Relocate   them  elsewhere   (setup   a   rubber   room   if   you   need   to)   and   assign   them   to   special   projects   (if   they   need   their   ego   stroked   in   the  interim).    Whatever   you   do,   you   need   to   ensure   that   the   last   people   remaining   have   or   can   develop   humility,   honesty   and  diligence  from  the  start.    You  will  need  these  parked  employees  later  once  you  have  a  strong,  thriving  IT  machine  into  which  they  can  be  re-­‐integrated,  but  for  now,  you  need  them  out  of  the  way  while  you  start  your  cleanup.  

Partition  your  non-­‐technical  staff  from  your  technical  team  members  Poorly  functioning  IT  groups  tend  to  have  grown  a  crusty  layer  of  non-­‐technical  people  that  have  integrated  themselves  into  the  technical  decision-­‐making  process.     They  are   there   for  a   reason  but   they  need   to  enjoy  a  peaceful   separation   from  the  core  technologists.    These  people  are  like  ash  on  the  coals…  they  insulate  the  glowing  embers,  preserving  some  energy  temporarily,  but  they  also  smother  and  suffocate  them  at  the  same  time.    Our  goal  is  not  to  churn  our  technical  resources  as  we  slowly  stifle  them,  rather  we  want  them  to  burn  brighter.    Look  for  middle  managers,  coordinators,  project  managers,  product  owners,  art  designers,   project   planners,   testers,   documentors,   and   executives   who   are   “along   for   the   ride”   but   aren’t   really   offering  meaningful   technical   expertise,   architecture  or   implementation.     There   is   a  place   for   the  non-­‐technical   people   and  we  need  them  to  continue  to  provide  the  vision,  prioritization,  wisdom,  and  coordination  that  they  offered  before,  but  we  need  to  label  them  “stakeholders”  and  not  “technologists.”    Be  brutal  in  your  definition  here.    If  they  aren’t  slinging  code  or  installing  servers  and  routers,  they  need  to  leave  the  room.    I  use  a  fun  image  here…  drive  the  car  or  build  the  car.    If  they  can  effectively  drive  the  car  (login  as  admin  and  “use”  software)  then  they  belong  in  the  stakeholder  group.    If  they  can  more  reasonably  build  the  car  (write  software,  compile,  build  and  deploy)  then  they  belong  in  the  technology  group.  

 

Liberate  your  technologists  and  elevate  your  thought  leaders  Your  software  developers,  router  admins,  server  admins,  automated  test  coders,  DBAs,  and  security  analysts  gather  around  and  look  up  to  thought  leaders  within  that  technical  team.    You  can  spot  them  right  away.    We  are  not  going  to  kill  their  spirit  by  making   them  managers,  but  we  are  going   to  elevate   them   into  a  prominent  architectural   role.    Do  not  make   the  mistake  of  appointing  a  popular  or  slick   imposter  here.    Technical   folks  are  soldiers  and  they  respect  one  thing…  another  soldier.     If   the  thought  leader  can’t  shoot  the  same  weapons  as  the  soldiers,  you’ve  chosen  the  wrong  person.    Here  you  need  to  identify  your  top   technologists   that  are  already  charismatically  AND  technically   commanding   respect  of   their  peers  and  get   them   into   the  role  of  peer  reviewer  and  merge  approver.    These  technical  leaders  will  have  their  role  further  cemented  as  worthy  of  respect  by  granting  them  “gatekeeper”  status  for  the  implementation  of  all  technology  initiatives.    Be  careful  here  as  your  work  toward  humility,  honesty  and  diligence  will  be  critical  as  you  make  your  selection  of  your  thought  leaders.    

You  have  now  unshackled  them  from  the  distractions  of  the  stakeholders  so  any  non-­‐technical  peer  pressure  should  be  gone,  and  you  have  provided  your  ground  troop  developers  and  sysadmins  with  leaders  that  they  can  naturally  respect  and  follow  –  technologically.     It   is  time  to  put  that  machine  into  operation  and  begin  the  process  of   implementing  new  processes  that  will  fuel  their    desire  to  learn  new  things  while  focusing  them  on  the  mission  at  hand.  

Implement  daily  standups  Many  dysfunctional  IT  groups  that  suffer  from  slipped  timelines,  false  promises,  and  reactive  swarm  responses  to  crises  suffer  from  a   very   common  malaise…   lack   of   followup  by   those  who   can  understand   the   status.     The   art   of   the  daily   standup  has  nothing  to  do  with  any  software  development   lifecycle  booklet.    Rather   it  provides  a  base,  human-­‐oriented  structure  of  peer  pressure.     If  you  are  relying  on  managers  to  whip  the  troops   into  a  motivated  direction,  you’re  missing  the  point.    The  team  needs   to   propel   the   team   members.     Daily   standups   are   not   a   podium   for   a   manager   to   preach   from,   rather   it   is   a   very  pragmatic  heads-­‐up  where  each  team  member  reports  on  what  they  did  yesterday  and  divulges  what  they  plan  to  work  on  the  current  working  day.    There  is  no  need  for  motivational  speeches  or  public  critique  here…  so  limit  your  involvement  to  keeping  the  statusing  on   track,   limit   conversation  of   solutioning   (your  meeting  will   fill  up  with   these  otherwise),  and  offer  extremely  brief  and  highly  sincere  thanks  for  positive  developments.     It   is  even  better   if  your  technology  thought   leaders  assume  these  roles  and  you  should  swiftly  help  them  develop   into  this  role.    The  most  sincere  thanks  from  a  fellow  technologist  can  be  as  simple  as  a  meaningful  nod  from  one  developer  to  the  other  when  they  kick  ass  on  a  really  tough  technical  issue  as  two  people  who  respect  each  other’s  technical  expertise  show  deference  and  respect.    The  daily  standup  is  your  friend  so  ensure  that  it’s  mandatory  and  failure  to  attend  should  result   in  an  HR  related  remediation  plan.    Those  that  don’t  attend  the  daily  standup  aren’t  being  there  for  their  team,  so  it’s  indicative  of  a  deeper  issue  that  needs  some  introspection.    Do  not  allow  stakeholders  into   the   daily   standups.     This   meeting   is   for   technical   folks   only.     This   is   where   the   sausage   is   made,   and   only   those   that  understand  sausage  should  be  in  attendance.      

Hold  weekly  architecture  reviews  Parcel   out   your   thought   leaders   and   have   a   more   insular   architecture   session   every   week.     This   is   not   a   parliamentary  procedure-­‐laden  UN  meeting…  this  is  more  like  talking  after  a  golf  game  with  your  top  technologists.    Ask  them  what  they  think,  not  about  the  projects  but  about  the  technologies.    Let  them  make  the  technology  choices,  tempered  by  your  awareness  of  the  high   level  business  vision  and  over-­‐arching  enterprise  technology  vectors  and  directions.    Counsel  them  on  new  technologies  that  need  research  and  get  their  real,  honest  opinion  on  them.    This  is  where  you  give  true  meaning  and  authority  to  your  top  technologists  and  they  will  breathe  this  freedom  in  like  oxygen  that  feeds  their  burning  passion  to  learn  new  things.    Then  stand  back  and  watch  the  innovation  that  surges  out  of  it.    By  limiting  this  group  to  the  powerful  few,  you  will  be  able  to  inspire  and  influence   the   technical   direction,   outside   of   committee,   and   outside   the   view   and   influence   of   politics,   and   far   away   from  subjective  uninformed  non-­‐technical  opinions.    You  will  also  turn  this  into  a  safe  technology  space  where  new  ideas  (even  bad  ones)   can   be   elevated   in   a   tolerant   peer-­‐architect   environment   so   by   the   time   the   consensus   technological   direction   is  established,  by  the  time  the  marching  orders  make  it  to  the  planning  sessions,  all  of  your  thought  leaders  are  in  agreement  and  will  support  the  initiatives.      Be  certain  to  get  a  nice  blend.    Have  one  front-­‐end  software  architect  and  one  back-­‐end  architect  in  the   room,   one   data   architect,   one   network   superadmin,   etc.     Try   not   to   double   up   to   avoid   stalemates   or   competition   in  direction.    Choose  your  lead  architects  and  then  give  them  real,  tangible  power  and  authority  to  govern  technical  choices.  

Segment  off  and  empower  your  stakeholders  The  age  of  the  good  buddy  watercooler  assignment  and  the  cherry  picked  executive  mandate  is  over.    Every  two  weeks,  hold  a  stakeholder   planning   session   which   is   attended   only   by   the   non-­‐technology   personnel   that   you   split   away   from   the  technologists  earlier.    Here   is  where  you  can  embrace  and  empower  your  non-­‐technology   folks  and   let   them  speak  honestly  about   strategic   direction,   priority,   and   business   objectives.     By   removing   all   technologists   from   this   meeting,   an   open  conversation  can  be  had  about  what  the  business  visionaries  think  about  how  the  current  technology  stack  solves  their  business  

 

needs  and  gives  them  an  opportunity  to  decide  what  should  be  worked  on  next,  and  how  those  can  be  organized  into  strategic  releases.    This  meeting   focuses  on   the  “What”  and  “Why”  of   the  project.    While   input   is  welcomed,  no  decisions   relating   to  “How”  or  “When”  should  be  finalized  in  this  meeting.  

The   first   few  meetings   here  will   be   lengthy   and   disorganized   as   the   stakeholders,   bereft   of   the   insulation   their   companion  technologists  provided,  will  wander  a  bit.    However  it  will  swiftly  snap  into  a  very  organized  delivery  of  lists  of  requests,  order  by  priority,  and  peaceful  requests  to  ask  for  the  technologist  team’s  feedback.    Each  stakeholder  should  submit  in  advance  of  the  meeting   their   ordered   list   of  wants.     Once   delivered   they   should   receive   no   promise   of   completion   or   deadline   in   that  meeting  and  they  will  be  invited  to  leave  the  room  so  the  technologists  can  weigh  in.  

Get  technologist  commitments  in  isolation  with  Weighing  and  Acceptance  Now  bring  in  the  technologists.    Share  with  them  the  list  of  wants  and  show  them  the  prioritized  order  of  them.    If  there  is  a  compulsion   to   explain  why   the   order   is  what   it   is,   I   would   not   indulge   that   too  much.     “What”   and   “Why”,   isn’t   really   the  mandate  of  the  technology  team  as  the  technologists  are  ceding  the  strategic  responsibilities  to  the  business  staff…  they  should  be  focusing  on  the  tactical  priorities  of  “How”  to  deliver  it  and  by  weighing  each  task  we  can  arrive  at  “When”  it  can  practically  be  delivered.    This  “weighing  and  acceptance”  session  is  where  the  technology  experts  can  evaluate,  outside  the  public  peer-­‐pressuring  eye  of  the  business  team,  the  size  of  each  task.    Once  they  have  established  the  size  of  each  task,  the  inevitable  and  welcomed  discussions  will  begin  of  how  to  optimize  and  deliver  on   these   tasks.     They  will   find  great  efficiencies  here  as   the  technologists   may   propose   using   a   single   task   to   implement   and   architect   an   enterprise-­‐wide   solution   that   will   solve   the  immediate  business  need  and  also  those  of  other  stakeholders  at  the  same  time.    They  will  also  begin  to  homogenize  platforms,  obsolete  old   legacy  methods,  and  explore  new  technologies  as   they  work  to  solve  the  tasked   items.    Essentially  you  want  to  allow  a  deep  amount  of  flexibility  to  allow  technology  experts  to  dictate  the  technology  direction  with  little  influence  and  direct  manipulation.     The   more   you   allow   the   stakeholders   and   non-­‐technical   resources   to   meddle   in   and   override   the   tactical  technology  direction,   the  worse  your  eventual   solutions  will  materialize  and   the  more  demoralized  your   technical   teams  will  become  as  they  will  find  they  have  little  meaningful  input  into  the  final  solution.  

Transparency  can  only  come  with  Responsibility  and  Bare  Consequences  As  the  team  engages  in  their  SPRINTs  their  first  few  will  be  disorganized  and  chaotic.    This  is  healthy  and  normal.    Distrust  of  the  new  process  and  even  belligerence  will  surface  during  the  first  critical  deliveries.    This   is  where  upper  management  becomes  critical  in  their  steady  support  of  the  implementation  and  transformation  of  the  team.    They  must  show  monolithic  support  for  the  transformative  effort  or  it  will  derail  swiftly.    As  the  technologists  claim  tasks  and  begin  the  implementation,  they  will  over-­‐commit  the  first  few  times.      They  will  try  to  remove  commitments  from  the  SPRINT,  they  will  try  to  allow  task  items  to  slide  into  the  following  SPRINT,  they  will  try  to  infer  that  there  are  dependencies  on  other  external  teams  that  block  their  deliveries.    The  responsibilities  for  all  tasks  they  committed  to  however  must  remain  squarely  on  the  people  that  claimed  them.    It  is  not  the  fault  of  one  single  developer  but  a  failure  of  the  entire  team  if  100%  of  the  SPRINT  priorities  are  not  met.    If  deadlines  get  slippery  and   the   technologists  are  allowed  pain-­‐free  opportunities   to  not  deliver,  you  will   lose   the   trust  of   the  Stakeholders,  upper  management  will  be  forced  to  intervene  and  the  entire  process  will  fail.    However  if  you  can  set  low  expectations  for  the  first  few  and  evolve   into  a  steady  rhythym  of  delivering  on  time,  the  necessary  trust  with  the  stakeholders  and  management  will   be   earned,   SPRINT  upon   SPRINT  until   the   technology   team  earns   a   reputation   as   the   steady,   quiet   deliverer   of   on-­‐time  products.      

Do  not  shield  the  technologists  from  the  fully  transparent  status,  but  also  infer  no  blame  on  individual  people.    The  truth  is  the  process  is  not  sufficient  to  deliver  quality  just  yet  and  work  should  be  done  to  continue  to  improve  the  process  so  no  individual  can  fail  and  the  team  predictably  succeeds  time  and  time  again.    These  improvements  can  include  having  lead  developers  vet  the   commitments  made   by   the  more   junior   ones,   using   the   scrummaster   role   to   consistently   review  mid-­‐sprint   status   and  reassign  tasks  where  needed,  etc.  

Let  the  technologists  get  their  moment  in  the  limelight  I  cannot  stress  the  importance  of  this  phase  of  the  SPRINT  enough.    Get  your  technologists  out  of  the  shadows  and  give  them  a  moment   to   demonstrate   their   accomplishments   at   the   end   of   every   SPRINT.     In   the   old   waterfall   environment   where   the  Business   Analysts   were   the   only   people   with   contact   with   the   end   customer,   the   developers   were   buried   behind   an  administrative   wall   where   they   lost   the   natural   human   contact   with   the   customer.     In   this   method,   once   per   SPRINT,   the  technologists  and  stakeholders  are  invited  into  a  room  to  share  the  glory  of  success  and  to  lament  the  raw,  transparent  failures  of  unmet  deadlines.    Do  not  let  technologists  off  the  hook  here.    If  they  didn’t  deliver,  they  need  to  be  the  ones  to  report  that  status.    It  is  uncomfortable  by  design  and  will  act  as  a  public  moment  of  harsh  responsibility  which  is  helpful  and  meaningful.    Even  past   failures  will  make   future  successes   that  much  sweeter  as  everyone   in   the  room  starts   to   learn   the   true  pattern  of  success:     Stakeholders   setting   forth   achievable   tasks   and   Technologists   delivering   meaningful   products   on-­‐time   and  

 

consistently.      Just  as  the  technologists  are  gently  prodded  into  delivering  on  time,  the  stakeholders  need  to  be  nudged  to  say  “Thank   You”   and   to   show   their   appreciation.     Demo   day   is   generally   a   celebration   time,   so   do   not   allow   any   statusing,  prioritization,   or   solutioning   to   happen   in   this  meeting.     Keep   it   simple   and   upbeat.     However   critique   should   be   allowed   if  deadlines  are  missed.    At   this  stage  of   the  SPRINT  the  stakeholder  will  not  have  had  the  opportunity   to  vet  each  deliverable  quite  yet,  but  do  allow  them  to  vent  if  such  is  needed.    The  goal  however,  as  the  teams  learn  to  trust  each  other,  is  to  turn  this  meeting  into  a  positive  experience  for  all  involved.  

Go  get  your  other  technologists  now  Once   you   have   developed   an   established   routine   and   the   stakeholder   and   technology   teams   have   bonded   in   trusting  relationship,  you  are  now  prepared  to  pull  those  other  developers  out  of  storage  that  you  had  to  quarantine  before.    Here  is  where  you  can  make  some  hard  decisions  relating  to  staffing  needs  and  suitability,  but   I  believe  that  you  should  reintroduce  your  tough  cases  slowly  back  into  the  successful  pipeline  as  much  as  possible.    Many  times  I  find  that  once  the  processes  are  improved   and   the   executive  management,   stakeholders,   and   the   bulk   of   the   technologists   have   faith   that   it   delivers   value,  anyone  that  in  the  beginning  that  was  recalcitrant  will  get  on  the  bus.    This  also  sets  the  best  victory  condition  for  your  problem  cases.    It  is  very  likely  that  the  reason  they  felt  disenfranchised  before  was  due  to  mismanagement  and  unwinnable  scenarios  (even  if  just  in  their  minds)  and  the  new  scenario  will  be  refreshing  for  them.    Just  be  sure  to  jealously  guard  your  transformed  team   and   ensure   that   no   influences   are   reintroduced   that  would   tip   the   scales   back   to   dysfunction.     It   is   so   challenging   to  establish  a  culture  of  true  effectiveness  that  once  you  find  it,  protect  it.  

Conclusions  This   is  simply  a  draft  of  my  thoughts  on  implementing  a  more  AGILE  environment  for  IT  teams,  but  the  basic  tenets  are  here  and  hopefully  this  can  serve  as  a  guide  to  those  diving  in  to  transforming  their  IT  departments.    Should  you  need  any  additional  hands-­‐on  guidance  in  restoring  your  IT  teams  please  feel  free  to  reach  out  to  me  at  jared@FUZIONAgency.com.