Archive for the ‘Technology Management’ Category

The [System Administrator’s] Oath

December 6, 2015

Bob Martin (author of Clean Code, The Clean Coder, and evangelist of software craftsmanship) recently posted The Programmer’s Oath. Let’s say we have jobs as System Engineer’s or System Administrator’s. We may write code to automate our work, to manage, maintain, and operate our systems and environments, but we don’t necessarily work as Programmer’s do writing applications for business functions. Would the Programmer’s Oath apply? Are its promises relevant to systems engineering/administration work? Perhaps it does. Here’s a version with some of the words changed as The System Administrator’s Oath.

In order to defend and preserve the honor of the profession of systems engineers and administrators,
 
I Promise that, to the best of my ability and judgment:

1. I will not create harmful infrastructure or systems.

2. The infrastructure and systems that I create will always be my best work. I will not knowingly make changes to infrastructure or systems that are defective either in behavior or structure.

3. I will produce, with each change, a quick, sure, and repeatable proof that every element of the infrastructure and systems work as it should.

4. I will make frequent, small, changes so that I do not impede the progress of others.

5. I will fearlessly and relentlessly improve the infrastructure and systems at every opportunity. I will never make the infrastructure worse.

6. I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.

7. I will continuously ensure that others can cover for me, and that I can cover for them.

8. I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.

9. I will never stop learning and improving my craft.

Regardless of how you might feel about taking oaths, Uncle Bob’s promises are something to contemplate as we constantly work to become better IT Professionals.

 

Advertisements

Your Last 30 Days

August 5, 2010

When a new US President is elected there is a focus on their first 100 days in office. The process seems to be credited to Franklin D. Roosevelt who met with Congress each of those first 100 days to pass new laws and establish new programs that quickly made a difference at the time.

When managers take new jobs some also start with a specific agenda for their first 100 days. I remember reading a good list of references on the Social, Agile, and Transformation blog which is written by Isaac Sacolick.

That’s all well and good, but how about when you leave a job? How should you handle the time immediately after your resignation as your notice period starts, your last 30 days (or maybe it’s your last two weeks)?

Leaving a job is in someways more important than starting. Resignations will be more important to the people who need to carry-on their functions and yours (the responsibilities you are vacating). In leaving a role, it’s important that a proper transition occurs so that the work, and especially the people (your soon to be former colleagues), are not impacted by your departure. An organized and proper transition is not only the professional thing to do, it is also the right thing to do.

Here are some ideas on how to organize a transition during your resignation period.

  • Create a transition document: On the day of your resignation be prepared with a transition document in outline form. There is no need at this point to have anything more than an outline because what you really want to achieve is to establish a forum with your colleagues (the ones who will carry your work forward) to identify the information that is important cover. Share the outline with your manager on the first day of your resignation and with anyone else your manager feels should be part of your transition process.
  • Summarize your time at the firm with an Introduction section: Include your first day with the firm and your last. Describe your function and your responsibilities (in your own words) and summarize the major contributions that you feel are important for your successors to know about. Provide a reference to your job description, and describe any promotions you may have received, or ways in which your job or your role changed over time.
  • Highlight Key Projects: Do a look-back of your work and write summaries for key projects that you accomplished. Include references to any exhibits or project artifacts (so that people can easily find the information), people who contributed to the projects with you (including outside vendors), and any future strategies for the project work that may have been discussed at that time or afterward. If there are projects that are still in-flight, considering labeling your project descriptions as completed (referencing a date) or active.
  • Highlight Vendor Relationships and Agreements: If you were responsible for managing (or coordinating) the relationships with any outside vendors, list contact names, phone numbers, and email addresses so those relationships can be re-established after you leave (or during your transition period). Summarize the external parties (including attorneys) who may have worked on contracts and agreements with you. Provide references to contract exhibits and summarize important contract points that will help your successors manage those agreements going forward.
  • Be a good citizen, clean-up after yourself: Sure, you’ll clean your desk and throw out unneeded documents and office supplies and you’ll return equipment (such as a laptop and Blackberry), but don’t forget about your system access. Create a list of your usernames and logins, any special permissions you may have had to applications, remote access methods, entries on emergency call lists (or call trees), and access cards to remote facilities; this list will help your colleagues decommission your access when you leave. Also check your calendar for any recurring meetings you may have organized and create a list so that meeting invites can be easily reissued.
  • Summarize Strategy: If you were in a role responsible for product architecture or strategy, or responsible for an important function within the firm, then your forward looking approach and plan will be important for your successors to understand. Describe your perspective for managing the function, any initiatives you were anticipating to start, or any ideas that you were contemplating but may not have had the chance to execute. New managers will certainly bring their own ideas and approach to your former function, but they will also appreciate all the help you can provide to get them started.
  • Take care of your people: If you are a manager responsible for people, make sure your manager (and/or your Human Resources department) is aware of any ongoing activities or promises that were made to your team members. Were you mentoring someone? Was someone promised a raise, a promotion, or a title change? Provide references to any performance review documents. Highlight the good (and the not so good) work habits of your team members so that your successors will be fair to your people as the management and the leadership of the function changes to accommodate your resignation.

When you resign from a firm you in fact take-on new responsibilities; and you will leave behind a large group of people who will assess your performance. It’s your opportunity to organize your transition so that others are not adversely impacted by your individual decision.

Agile is not fast, it’s frequent.

July 23, 2010

The principles (and the intention) of Agile Development are often confused with the word agile which people interpret to mean fast (in the sense of being quick and doing things other than in a thorough way). Of course that is an incorrect interpretation. Agile methods are not intended to be fast, if anything Agile teaches us to be iterative, repetitive, and to break down larger problems into smaller pieces that can be more easily understood, completed with higher quality, and delivered on an expected schedule. From that perspective, Agile teaches us to be Frequent in the way we approach our work.

So Frequent may in fact be another principle of Agile Development. As a principle it doesn’t only have to apply to software development work. We can apply Frequent methods to other disciplines too.

Corporate Practice

November 1, 2009

As managers we work hard at choosing the best individuals for a job. We write job descriptions, conduct searches, and choose the best people we can find (the best educated, the most experienced, the best trained) for the roles in our groups. But having the best individuals doesn’t automatically create better teams. Managers are constantly challenged with the inefficient and inferior results that develop by people working as individuals, not sharing information, and not collaborating with colleagues. Conducting work in silos ultimately hurts innovation.

Why is collaboration so hard, why is it an unnatural way of working for most individuals? Kent Beck has a perspective on the situation in his book Extreme Programming Explained: Embrace Change. As Beck views it, the influences for individual performance start with our very early academic training and the typical reward systems found in the work environment:

It’s hard to collaborate. Our whole education system is tuned to individual achievement. If you work with someone on a project, the teacher calls it cheating and punishes you. The reward systems in most companies, with individual evaluations and raises (often cast as a zero sum game), also encourages individual thinking.

(Quoted from page 152 in the first edition of the book.)

The analogy (or thought experiment) that I sometimes like to use is about a professional baseball team. In the Majors players are selected to be the best in their positions. The process of scouting players, training them through the minors, and bringing them up to the Major League teams has been very well developed over multiple decades. The players chosen for the Majors are the best and the most skilled in their individual positions; the best pitchers, catchers, fielders, etc. You can’t find better individual players than those that are chosen to play in the Major Leagues.

Yet, the manager of a baseball team requires practice. Then the question that develops is, if the players are the best and the most skilled, why is practice necessary? And the answer, which isn’t immediately obvious to many people, is that practice is necessary to make a better team. Practice is working together, collaborating, allowing a second baseman to know the throwing habits of a catcher when trying to throw-out a runner stealing base, for example. Practice is when a first baseman learns the nuances in the step of a pitcher when he is about to throw to first base. Or when a shortstop learns to cover for the second baseman who is fielding a right-side grounder. The perspective on practice and what teams do during practice is what makes a baseball manager great, what creates great teams, and ultimately what distinguishes one team from another in the Major Leagues.

If you connect with that analogy, if you find that you are dwelling on the idea more as a thought experiment, there is one last question to consider to tie it together with the corporate world: What is the analogy to “practice” in a company made-up of knowledge workers?

“Meetings” in a corporate setting are the equivalent of practice. Meetings imply collaboration because they require more than one person. Meetings are where perspective develops across teams, where information is shared and judgment is improved across individuals, where people learn the nuances in the capabilities (or limitations) of other individuals. Meetings, even if viewed as ad-hoc discussions between two individuals, are where better teams are ultimately created. And like practice in baseball, meetings are a manager’s best tool to drive collaboration, to create higher performing teams, and ultimately to develop excellence in an organization.

Note, this posting was motivated by Issac Sacolick and the Social, Agile, and Transformation Blog. See Issac’s post and the dialog that developed in the comments section for additional background:

When Ogranizational Silos Hurt Innovation

http://ctotodevelopers.blogspot.com/2009/10/when-organizational-silos-hurt.html

Communicating for Quality

October 12, 2009

While in Los Cabos, Mexico we stayed at an excellent hotel named the Hoteles Marquis. Like all memorable hotels the Marquis has a terrific location right on the Pacific coast, it’s buildings are beautifully architected, and their service is top-notch and high quality.

Decisions of location and architecture are strategic and discrete; those decisions are made upfront and you go with them through the life of the hotel’s property and business. Service, however, is different. It is obviouly hard to develop a high quality service and service is on-going, it’s something that you constantly work on.

One morning at the Marquis we were waiting around in the hotel’s outdoor lobby for a bus to take us to an ATV adventure through the Mexican desert and coast. I was having coffee at the top of a short flight of stairs that led to a stone and tile landing connecting another flight of stairs. A young man working for the hotel and sweeping the landing part caught my attention.

At first the floor didn’t appear dirty to me. He was using a wide angled broom to collect the dirt and sand into small piles that he later swept into a stand-up dust pan that had a long handle. He worked meticulously, using the longer part of the broom to clean the corners where the landing met an adjacent wall. And he worked thoroughly, sweeping each area multiple times until he was sure that part of the floor was completely clean. He was also organized and he was methodical covering every square inch. I was impressed.

For a moment I wondered how his managers at the hotel might have trained him to be such a great sweeper. They could have shown him to use the angled edge for corners and to think in patterns so he got the best coverage. Maybe his manager worked with him a few times and then periodically watches him work to make sure he’s keeping-up with the service quality standards of the hotel. But in fact I don’t think that’s the way they do it. That young man was too detailed and too passionate about the way he was going about his work. Instead I think the only direction he got from his managers was to make the floors beautiful for the hotel’s customers and guests. And the young man tirelessly dedicated himself to deliver the best quality he possibly could to his job.

What’s the Difference Between Development and IT?

January 25, 2009

For anyone in the technology management business that should be a very obvious and simple question to answer: Development is about programming and creating software applications and IT is about installing and managing servers and networks. While those are true and accurate differences, there is less value in obvious and simple answers and what we really want is something more meaningful. What if we’re looking to understand the nature of the processes used to manage development and IT functions and how those processes are different? What if we’re looking for the influences that make an application developer’s job different from a system administrator’s? How would you respond from that perspective?

Broad and open questions are really meant to be debated, but let’s try to put a stake in the ground and consider a response; so here’s one perspective. When Developers interact with end users it’s to define a new feature in an application. Usually a single end user or a single business group owns the definition. Once the feature is understood and defined, a developer creates the feature and delivers it to the end user after some period, usually on the order of days, weeks, or in some cases longer. When the feature is delivered, the process starts over again to define the next new feature which is always different from any of the previous ones.

When IT managers interact with end users it’s to deliver something that’s already defined. For example, an end user may need a new desktop, a faster notebook, a replacement Blackberry, or a new fileserver share to store documents. Since what they’re asking for is already defined, the end user expects that the request will be delivered quickly, in hours or in a few days (at most) and it will be delivered in working order exactly the same as the previous times (which is not at all unreasonable from the end user’s point of view).

So Development is in the business to deliver new things over-and-over again, and IT is in the business to deliver the same thing over-and-over again quickly.

And that’s one way to answer the question in a single and meaningful discrete statement. But be careful not to underestimate the differences. In software development there is a one-to-one relationship between the definition of a feature to its delivery. For example, an end user wants a new button on a screen to perform a function. An end user will define the button and the function and a software developer delivers the new button and its associated function. That’s one-to-one, one definition to the delivery of one feature.

On the other hand, in IT there is one definition that is applied to many deliveries. For example, an end user wants a specific set of software applications to be included on desktop computers and an IT manager configures and delivers the desktops to multiple end users in a department. That’s one-to-many, one definition to the delivery of many desktops. And unlike Development, in IT the deliveries are not distinct and usually occur over an extended time period.

There are additional differences. In Development there is typically a single business owner who defines the feature, however, in IT, definitions usually have to satisfy multiple business owners sometimes across multiple departments that are operating different business functions.

In an IT function it’s easy for the definition behind a delivery to be become out-of-date, stale, and sometimes inaccurate as hardware is upgraded, software updates change features of vendor-based applications, or when feedback from multiple end user groups change the definitions in small incremental ways over time.

IT groups also have the challenge of keeping the already deployed systems in-sync. When Blackberry releases a software upgrade, for example, in some cases new hardware devices may require the new software version to function, and in others the new software may not work on older devices, which results in a deployed base of devices that can work differently from one another. However, from the end user’s perspective they provided a definition for a mobile email device and a Blackberry is a Blackberry and each one should work the same way.

An organized IT group will maintain definitions for end user requirements in the form of Build Documents and attempt to keep them up-to-date. However, as business groups grow, objectives change, and collaboration scenarios between business teams expand, end users aren’t oriented to inform IT of the changes and in many cases it becomes the responsibility of IT to initiate dialog with end users to update requirements (rather than end users initiating the dialog which is generally the case when new application features are needed from Development teams). In addition, IT frequently has to manage, and sometimes rationalize, conflicting requirements from multiple end user departments that may come up over time. Since a Development function delivers one feature to one requirement, the dialog with end users is usually more current with the request.

Also be aware of the analogy between the “source code” of an application and the “configuration” of a product (such as a desktop, server, or network device). End user groups generally have an understanding that developers need time to change and test source code. But since end users expect IT to deliver the same thing over-and-over again quickly, there is not a similar understanding that IT needs time to change and test configurations. And making matters more difficult for IT, there are many good versioning systems to help manage changes to source code, but system “configurations” in many cases are disjointed and can’t really be versioned and controlled like applications’ source code.

So what can be done to improve the situation and avoid problems? Well first, IT managers and others responsible for an IT function should be aware of the underlying nature of Development vs IT processes. IT managers should maintain a collaborative and productive process with business groups and keep-up with requirement definitions in a Build Document type format that captures any differences between end user groups. IT managers should also attempt to make the nature of their function transparent so business-side teams have a basis to understand the processes that are used to manage infrastructure-based deliveries.