Archive for the ‘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.

“Reviewing performance is good; it should happen every day.”

July 9, 2010

NPR posted an interesting article on a interview with Samuel Culbert, a UCLA business professor and author of the book Get Rid of the Performance Review! You can access the NPR article here.

The article (and I would expect the book) offer some excellent perspectives on performance reviews in the workplace. Feedback on employee performance is not something that can be scheduled for once or twice a year. To be effective, and to create cohesive and high performing teams, feedback must be constant and ongoing. Managers should be observers of performance and should develop skills for understanding human nature and giving accurate and helpful feedback to enhance and improve performance.

If there is anything more insidious than a once or twice yearly performance review it is a 360-degree review process. If managers, whose job it is to be responsible for people, to provide useful feedback, and to understand human nature, don’t have the proper communications and collaboration skills to provide proper feedback, how can individuals (ie, managers and non-managers alike) contribute to a 360-degree review process in a way that is productive or even fair? It’s a rhetorical question, obviously they can’t.

I like the perspective communicated in this part of the article:

How often have you heard a manager say, “Here is what I believe,” followed by, “Now tell me, what do you think?” and actually mean it? Rarely, I would bet. Bosses seldom show that kind of respect.

That type of dialog initiated by managers is not only respectful, it’s collaborative and it also sets an important precedent in the way people work with each other at all levels inside an organization. That type of dialog is in fact cultural. And corporate cultures based on solid principles that empower and treat people fairly create the best organizations.