Upload
jared-nielsen
View
10
Download
2
Tags:
Embed Size (px)
Citation preview
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 [email protected].