Professional Development

(Personal) Kanban Myths: The Myth of The Process

Recently, my friend Joe Webb has posted some great resources on Personal Kanban on his Facebook timeline. Joe’s an influential guy in the tech community (particularly the #SQLFamily), so I’ve been excited about the flurry of emails and comments regarding the adoption of Kanban techniques. I’ve been using Kanban boards for a while now at work, and it’s interesting to see the differences between Personal Kanban and “industrial” Kanban. The significant distinction between the two appears to be the impetus to “get things done” in Personal Kanban by using a very simple abstraction; in other words, start with a simple board of “To Do”, “Doing”, and “Done” and attack your task list.

I think this is a great way to get started with Kanban, but I also think that it’s easy to forget about some critical components of Lean thinking. After observing a couple of email chains from friends (and comments on Joe’s Facebook thread), I thought I’d blog about some common misconceptions of Kanban, starting with:

Myth 1: Kanban is a process to manage my task list.

This is probably the biggest trap that most people fall into when they decide to get started. The simplicity of Kanban is so appealing; just throw up a board and start moving cards left to right. Getting things done; Kanban helps you do that, right?

Sort of. Kanban is not a process; it’s a visualization of your process. The distinction may appear to be subtle, but it’s important. A simple board showing three columns (i.e., “To Do”, “Doing”, and “Done) assumes that your method of handling tasks is equally simple. Your process should drive your board, not the other way around. While the act of defining tasks will yield some immediate benefits, oversimplifying the visualization has some costs.

As a concrete example, let’s assume that one of your tasks is to call and make an appointment with your doctor. You move the card to the Doing pile, call your doctor, and then get informed that they’ll have to call you back. Can you move the card to Done? You haven’t made the appointment. Do you leave the card in Doing? Are you doing anything with it besides waiting? Do you move it back to To Do? You’ve already started working. If your board is driving your process, the temptation is to leave the board alone and struggle with task movement. If your process is driving your board, you change the board. Add a column for waiting tasks, move the card, and then revisit that pile as needed.

Don’t get me wrong; starting with a simple board is a GREAT way to get started with the fundamentals of visualizing workflow, especially if you don’t know what your process is yet. However, as you discover more about the way you work, don’t try to change the process (at first); make sure that you spend some time developing your board so that it matches the way you do work. Improvement will come later.

#SQLPASS–Good people, bad behavior…

I’ve written and rewritten this post in my mind 100 times over the last couple of weeks, and I still don’t think it’s right. However, I feel the need to speak up on the recent controversies brewing with the Professional Association for SQL Server’s BoD. Frankly, as I’ve read most of the comments and discussions regarding the recent controversies (over the change in name, the election communication issues, and the password issues), my mind keeps wandering back to my time on the NomCom.

In 2010, when I served on the NomCom, I was excited to contribute to the electoral process; that excitement turned to panic and self-justification when I took a stance on the defensive side of a very unpopular decision. I’m not trying to drag up a dead horse (mixed metaphor, I know), but I started out standing in a spot that I still believe is right:

The volunteers for the Professional Association of SQL Server serve with integrity.

Our volunteers act with best intentions, even when the outcomes of their decisions don’t sit well with the community at large. However, we humans are often flawed in our fundamental attributions. When WE make a mistake, it’s because of the situation we are in; when somebody else makes a mistake, we tend to blame them. We need to move past that, and start questioning decisions while empathizing with the people making those decisions.

In my case, feeling defensive as I read comments about “the NomCom’s lack of integrity” and conspiracy theories about the BoD influencing our decision, I moved from defending good people to defending a bad decision. This is probably the first time that I’ve publically admitted this, but I believe that we in the NomCom made a mistake; I think that Steve Jones would have probably made a good Director. Our intention was good, but something was flawed in our process.

However, this blog post is NOT about 2010; it’s about now. I’ve watched as the Board of Directors continue to make bad decisions (IMO; separate blog forthcoming about decisions I think are bad ones), and some people have questioned their professionalism. Others have expressed anger, while some suggest that we should put it all behind us and come together. All of these responses are healthy as long as they separate the decisions made from the people making them, and that we figure out ways to make positive changes. Good people make mistakes; good people talk about behaviors, and work to address them.

So, how do we work to address them? The first step is admitting that there’s a problem, and it’s not the people. Why am I convinced that it’s not the people? Because every year we elect new people to the board, and every year there’s some fresh controversy brewing. Changing who gets elected to the board doesn’t seem to seem to stimulate transparency or proactive communication with the community (two of the biggest issues with the Professional Association for SQL Server’s BoD). In short, the system is not malleable enough to be influenced by good people.

I don’t really have a way to sum this post up; I wish I did. All I know is that I’m inspired by the people who want change, and it saddens me that change seems to be stunted regardless of who gets elected. Something’s gotta give at some point.

*************
Addendum: you may have noticed that I use the organization’s full legal name when referring to the Professional Association for SQL Server. Think of it as my own (admittedly petty) response to the “we’re changing the name, but keeping our focus” decision.

Managing a Technical Team: Building Better

Heard a great podcast the other day from the team at Manager Tools, entitled “THE Development Question”. I’m sorry to say that I can’t find it on their website, but it did show up in Podcast Addict for me, so hopefully you can pick it up and give it a listen. I’ll sum up the gist here, but it’s really intended to be a starting point for this blog post. In essence, Manager Tools says that when a direct approaches you (the manager) with a question, one of the best responses you can offer is another question:

“What do you think we should do?”

Their point is not that management is a game of Questions Only, but that leaders want to develop others and development comes through actions; employees have lots of reasons for asking questions, but a good manager should realize that employees need to be empowered and able to take action for most situations. If an employee is constantly waiting on approval from the manager, then the manager becomes the bottleneck.

Mulling on this a couple days made me realize that there’s a potential hazard for most new technical managers related to the issue of employee development; are we doing enough to make our employees better engineers than we were? Let me walk you through my thinking:

Most new technical managers were promoted to their position from within their company, and it was usually because they were the best operator (i.e, someone who was skilled at their job as an engineer).
Most new technical managers have a tough time separating themselves from their prior responsibilities, particularly if those prior responsibilities were very hands-on with a product\service\effort that’s still in use today (e.g., as a developer, John wrote most of the code for the current application; as a manager, John still finds himself supporting that code).
If you were the best at what you did, that means that the people you now manage weren’t. Actual skill level is debatable, but most of us take a lot of pride in what we do. Pride can overemphasize our own accomplishments, while downplaying the accomplishments of others.

This is a problem for technical management, because the goal of a good manager is NOT to solve problems, but rather to increase efficiency. Efficiency is best achieved by distribution; in other words, you as a technical manager could learn how to improve your own technical skills by 10%, but if your employees don’t grow, your team’s not really making progress. On the other hand, if you invest in your directs’ growth and each f them improves their technical skills by 10%, it’s a bigger bang for your buck (unless you only have one employee; if that’s the case, polish your resume).

Here’s the kicker: Sacrificing your technical skills while building the skills of your employees will pay off more in the long run than continuing to build your own technical knowledge alone. You WANT your employees to be better engineers than you were because you gain the advantage of the increased skills that brings to the table distributed and magnified by the number of employees you have. I’m not saying that you should completely give up your passion for technology; it’s helpful for managers to understand the challenges their employee’s face without necessarily being an expert (that’s a fundamental principle of Lean Thinking; “go see” management). However, you should strive to be the least technical person on your team by encouraging the growth of the rest of your team.

So let me ask you: “What are you doing to develop your employees today?”

2014-08-18 by Stuart Ainsworth Professional Development SQLServerPedia Syndication 0

Managing a Technical Team: Act Like a Good Developer

This is one of my favorite pieces of advice from my Managing a Technical Team presentation that I’ve been doing at several SQLSaturdays and other conferences: act like a good developer, with a different focus. Most new managers, especially if they’ve been promoted from within (the Best Operator) model don’t know how to improve their management skills. However, if you were to ask managers what makes a good developer, you’ll probably get a series of answers that are similar to the following broad categories:

Good Developers have:

a desire to learn,
a desire to collaborate, and
a desire for efficiency.

I could probably say that this is true for all good employees, but as a former developer, I know that the culture in software development places a lot of focus on these traits; system administrators usually have different focus points. However, all technical managers SHOULD emulate these three traits in order to be effective. Let me explain.

Desire to Learn

Let’s imagine Stacy, a C# developer in your company; by most accounts, she’s successful at her job. She always seems to be up on the latest technology, has great ideas, and always seems to have a new tool in her toolkit. If you ask her how she got started programming, she’d tell you that she picked it up as hobby while in college, and then figured out how to make a career out of it. She’s an active member of her user group, and frequently spends her weekends reading and polishing her craft; while not a workaholic, she does spend a great deal of her personal time improving her skills. She’s on a fast track to managing a team, in part because of her desire to learn.

One day, she gets promoted, and is now managing the development team; she struggles with the corporate culture, the paperwork, laying out a vision, and can’t seem to figure out how to motivate her team to the same level of success that she was achieving as a developer. The problem is that her desire to learn no longer syncs up with her career objectives; Stacy needs to invest her educational energies into learning about management.

Ask a new IT manager what books they’re reading, and typically the response will be either none at all, or a book on the latest technology. We tend to cling to that which is familiar, and if you’ve got a technical background, it’s easy and interesting to try and keep focusing on that background. However, if you’re serious about being a manager, you need to commit to applying the same desire to learn that you had as an employee to learning more about management. Sure, pick up a book on Big Data, but balance it out with a book on Relationship Development. Podcasts? There’s management ones out there that are just as fun as the development ones. Webinars? Boom.

Desire to Collaborate

Bob’s a data architect. Everybody loves Bob, because he really listens to your concerns, and tries to design solutions that meet those concerns; if he’s wrong about something, he’s quick to own up to the mistake, and moves on. He works well with others, acknowledging their contributions and adapting to them. In short, Bob is NOT a jerk; nobody wants to work with a jerk.

Bob gets promoted to a management position, and he too struggles; he’s still hanging out with his former teammates, and is still going to the same conferences. Everybody still likes Bob, but he’s having trouble guiding his team in an effective manner. He hasn’t really built relationships with his new peers (other managers that report to his director), and hasn’t found ways to manage more effectively. He’s collaborating, but with the wrong people.

As a new manager, you should continue to maintain relationships with your directs, but you need to build a relationship with your new team of peers. Understand their visions, and find ways to make your team valuable resources to them. Reach out to other managers at user groups and conferences; build a buddy system of people based on your management path, not just your technical one.

Desire for Efficiency

If you sat down and had a conversation with any development team that was effective and producing results and asked them about their methodology, it wouldn’t be long before they started talking about frameworks. Efficiency in development is derived from reusable patterns and approaches to problems; they’re tough to implement at first, but the long term gain is enormous.

As you’ve probably guessed, there’s management frameworks that can be very effective in a technical environment; investing time in implementing them can yield great efficiencies when faced with making decisions. In my current environment, I use three:

MARS – my own self-rolled approach to system operations; it’s not perfect, but it helps focus efforts.
Kanban – allows me to see what our WIP (Work In Progress) is, and helps queue up items for work
ITIL – we’re just starting to adopt this, but we’re working on isolating Incident Management from root cause analysis, as well as implementing robust change control processes.

The challenge with management frameworks is similar to that of development frameworks: bloat. It’s too easy to get bound up in process and procedures when lighter touches can be used, but in most cases, the efficiency gained by having a repeatable approach to decisions allows you to respond quickly to a changing environment.

Summary

Management is tough, but it’s especially tough if you continue to focus on your technical chops as opposed to your leadership abilities. Act like a good developer, and apply those same basic principles to your team.

2014-08-04 by Stuart Ainsworth Professional Development SQLServerPedia Syndication 0

Steel City SQL Users Group–March 18, 2014– @SteelCitySQL

Next Tuesday, I’m loading up Big Blue, and driving over to Birmingham to present at the Steel City SQL Users Group. I’ll be talking about the Agile DBA. Should be fun!

http://www.steelcitysql.org/

Featured Presentation

The Agile DBA: Managing your To-Do List

Speaker: Stuart Ainsworth

Summary: Agile development is all the rage, but how do the principles apply to database administrators? This presentation will introduce the basics of the Agile Manifesto, and explain how they can be applied to non-development IT work, such as database administration, maintenance, and support. We’ll cover scrum (one of the most popular development methodologies) and kanban, and identify some of the common struggles with implementing them in an organization. This is an interactive discussion; please bring your tales of success and your horror stories.

About Stuart: Stuart Ainsworth (MA, MEd) is a manager working in the realm of financial information security. Over the past 15 years, he’s worked as a research analyst, a report writer, a DBA, a programmer, and a public speaking professor. In his current role, he’s responsible for the maintenance of a data analysis operation that processes several hundred million rows of data per day.

2014-03-14 by Stuart Ainsworth Conferences Professional Development SQL SQLServerPedia Syndication User Groups 0

The Evolution of the DBA

Recently, there’s been a couple of great posts about the Death of the Database Administrator, including a response by Steve Jones and a several reactions by the staff of SQL Server Pro; the central premise behind the supposed demise revolves around this one major thought:

The evil cloud has reduced the need for internal systems infrastructure, including database administration. It’s a storm of needs for faster development (agility) and the rise of hosted services; who needs a database server, when you can rent space on Azure? Please note that I’m not specifically anti-cloud, but I’m casting it as the villain when careers are on the line.

Furthermore, in shops where the cloud is banned (e.g., financial services), developers are using tools like Entity Framework to write SQL for them. Tuning SQL thus becomes an application change as opposed to a stored procedure change; DBA’s who do performance tuning have to focus on index maintenance and hardware acquisition. Code tuning is now part of the development domain, and the career of the pure SQL developer is gasping in comparison.

Like all great controversial statements, there’s an element of truth; the cloud, agile approaches, and new technologies are reducing the need for traditional database administrators, but I think we’re a long way away from pulling the plug. However, I will say that over the next decade, these trends will probably continue to grow, eating away at the availability of jobs that do strict database administration (and the SQL developer will probably expire altogether). But not yet.

What this does mean is that if you are intending to be employed 10 years from now, and you’re a database administrator, you’ve got two choices to make today:

Master a specialty. If you’re planning on consulting for a living, this is a great choice. Get so intimate with the database product of your choice that you become the go-to person for problem-solving. Companies that have large installations of SQL Server will need secondary support as the product becomes easier to maintain (and big problems get obfuscated by GUI’s).
Expand your horizon. Instead of focusing on super in-depth mastery of your database platform, broaden your perspective; if you’re a SQL Server guy like me, start learning a little bit about SSRS, SSAS, and SSIS (if you don’t already know it). Spread out into Hadoop, and NoSQL; dabble in MySQL and SQLLite. Understand what the cloud can do, and where it makes sense to use it.

So go deep or go broad, but go. I wouldn’t start quaking in my boots just yet about the demise of your career, but change is coming; those who adapt, survive.

For me? I’m going broad. I’ve built a home-brewed server, and downloaded a copy of the HortonWorks Hadoop Sandbox. Stay tuned for my adventures with Hadoop.

2014-02-06 by Stuart Ainsworth Code Education Professional Development SQLServerPedia Syndication 2

PASS 2013 Summit Evals are out!

And I didn’t do too bad; wish I had done better. I said that when I was done, I felt like it was a “B” level presentation, and it was; I got a 4 out of 5 on my evals. If I had been a less experienced speaker, I would be thrilled with that; as it stands, I’m a little bummed. I know that it’s tough to get accepted to speak at Summit, and I feel bad that I didn’t hit this one out of the park.

However, it was a great experience; 73 people attended my session, which is a big audience for me. I struggled with my demos throughout (I don’t even want to listen to the audio because I’m worried about how bad it was), and I should have worked on finding ways to better connect with my audience. The feedback I got was really constructive:

Was a good intro, just would have liked to have seen some broader examples. For example converting XML into relational tables, not in detail but just at a high level.

Lots of demos geared towards people who have already written a lot of XQuery. This should have been a 201 session. A discussion on why you’d even use the XML datatype would have been useful. What problem does the XML datatype even solve for people?

I think I would have benefitted from a hard copy (gasp) of the XML data. I would have been able to see the data and compared it to your on screen results

Way too fast, too ambitious for a 101 session

Well put together and paced. Very clear and coherent

Scale back expectations if it really is a 101 level session

So it sounds like I didn’t do the best job of making my abstract clear; people had different expectations than what I had for what a 100 level course was supposed to be. I do agree that it was too much content, and if I present on the topic again, I’ll be sure to go back to splitting this up to focus on the basics of XPath, and save a discussion of FLWOR for later. Also, I really should have used demos much more judiciously; I kept running code and trying to work the magnifier, when I should have just used slides for the basics, and then done a much more thorough demo.

So what did I learn? Connect with the audience first and foremost. If I could have kept them engaged and entertained, I may have covered less material, but may have inspired them to do more research on their own (which in the end, is the point of this whole exercise).

2013-11-07 by Stuart Ainsworth PASS Professional Development SQL Server SQLServerPedia Syndication 0

MaTT: Entropy

Decided to take a detour today in my blogging thoughts (it is Friday, after all), and opted to revisit the issues of managing a technical team (MaTT); today’s topic: Entropy.

en·tro·py

/ˈentrəpē/

Noun

A thermodynamic quantity representing the unavailability of a system’s thermal energy for conversion into mechanical work, often…

Lack of order or predictability; gradual decline into disorder.

Simply put, processes decay over time. A good manager will recognize this, and learn to intervene when those processes begin to break down. In contrast, code lives on forever (unless someone steps in to change it).

Let me give an example; about a year and a half ago, I implemented Kanban as a method of managing our workflow in the production environment. My team quickly adapted to it, and it became very easy to see exactly what people were working on, and what was getting accomplished. I thought “my job here is done”, and moved on to other things, occasionally touching base with the Kanban board to see what was going on.

This week, I realized that the process had degenerated; sure, my team was still using the board to report what they had done for the day. However, they’ve gotten in the habit of solving the problem, and then creating the card in the Done pile. Entropy. I am no longer able to predict or measure what is being done or what needs to be done.

I’m out next week (hoping my son is born by the end of the week), but when I return, I need to intervene and work toward cleaning up the process. While I firmly believe that I should trust my team and encourage them to make the right decision, part of the management process is learning when to intervene in order to shore up a process that is decaying.

2013-06-21 by Stuart Ainsworth Professional Development SQLServerPedia Syndication 1

MaTT: You have to start somewhere

So, January came and went, and no post from me. I continue to suffer from writer’s block, but I’ve finally cobbled together enough ideas that I feel like I can put a couple of quick posts out there. I’m still struggling with learning how to manage a technical team (MaTT) as opposed to being a technical person, but here’s another concept I’m beginning to grasp.

You have to start somewhere.

When I began managing my team, I was tempted to rush in and save the day. I know where a lot of the problems are, and I know which ones are big, and which ones are not. I kept thinking that if I could just motivate the team to start attacking the problem, then we’d be sitting pretty in a year.

I was wrong.

Most people are already motivated to do their jobs; if they’re not, then they’re in the wrong position, and it’s hurting them as well as hurting the company. What a team is usually looking for in a manager is to help them make priority decisions, and to back them up when they need things to change. Here’s the conundrum: Technical people often (logically) focus on changing the things that hurt them the most. Your DBA may say “I keep having to babysit this query for the boss because it’s slow, and it’s slow because the developers don’t know how to normalize a database; can we refactor everything?”. Your developers may say “If we had more time to rebuild everything, we could fix that query; can we hire another person or put these features on hold so we could tune everything?”. Your boss may say “We need to make a profit; what’s the most cost-effective way to manage our database architecture moving forward?”

If you focus your energy on addressing the technical issues without giving consideration to the profitability of your company, you’re spinning your wheels. However, you MUST figure out a way to ease the pain of your technical team by addressing their concerns. It’s no secret that I’m a Lean/Agile kind of guy; I truly believe that these philosophies can help balance the scales between support/development/operations, but you have to start somewhere.

“Somewhere” for me is the small fixes; don’t tackle the big projects head-on. Focus on being successful at a couple of small things (e.g., reduce the number of support calls in a measurable fashion, or refactor some small but essential bit of code). Make sure that these changes are measureable, and make sure that you report the changes to your boss AND to your team. This accomplishes two things:

It shows measurable progress (in my experience, bosses love metrics), and
It encourages your team by giving them a couple of quick successes.

If your team doesn’t see progress, then in their mind, “nothing is being done”. Your boss wants to know how you’re improving efficiency and effectiveness in terms of dollar signs; your team wants to know that they’re solving a technical problem. Make sure you can address both of those needs.

More to come.

2013-02-06 by Stuart Ainsworth Professional Development SQLServerPedia Syndication 0

Transitioning into Management; lessons learned…

This has been a busy year for me; apart from all of the personal news, I’ve spent the last year feeling out my new position as a manager. While is not my first job as a manager (I spent about 3 months as a manager working for a department in a death spiral in 2002), it’s been a bit of a bumpy ride. I’m learning as I go, which is a great skill to have as a technical person, but tricky in a management position. Here’s a short list of things I’ve learned over the last year, and I hope it’ll be useful to those of you that are making that transition yourself:

1. These ain’t the problems you’re used to solving.

As a database person (DBA, Developer, Architect), I was very accustomed to tackling technical challenges on a daily basis. Disk running out of space? Check for unexpected log growth. Bug in a procedure? Rewrite it and test. I just assumed that as a technical manager (managing a group of DBA’s) that I would continue in that vein, just with more help and more paperwork. I was wrong (so wrong).

You see, most of the problems I face today aren’t technical; they’re people and processes. I’ll talk more about the people in a bit, but the process issues stem from things like "we can’t get this bug fixed because the devs are busy writing new features” or “I have 35 things to do on my top priority list; which one do I do next”. As a manager, my primary obligation is not to make sure that technical problems are addressed, but rather to make sure that there are no impediments for my team to implement technical solutions.

2. The people in your department aren’t you.

And they don’t solve problems like you do; they have their own systems, answers, and methods to get to those answers. While it may sound conceited, I think I was a damn good database person as an employee, and I think it was those skills which ultimately led to this opportunity. However, I have quickly learned that not everyone approaches problems the way I do, and I can’t simply jump in and solve the technical problem for somebody. It’s tough, especially when I see that one of my employees took a few hours to google something I knew how to do blindfolded, but I have to let them learn at their pace (and encourage them to learn faster).

One thing I have learned is that I have to make time to pass on my skillset, and that’s not a one-time thing. I need to spend some recurring time collaborating with my team so that I can step away from solving the technical problem and focus on the impediments (see rule 1 above).

3. Don’t let the drama get to you.

As an employee, it was fun to be snarky. When something (or someone) ticked you off, you could go ahead and rant about how stupid the decision was or how bad the system sucked, all the while knowing that you would be doing your best to fix the problem the next day. Your words didn’t really mean much; it was just a way of blowing off steam. As a manager, other people are watching you, and you can’t blow off steam (in front of them). Compounding the problem is the fact that as a manager, people come to YOU to rant. All you can do is listen and try to get to the core of the problem; again, if there’s a real issue where it looks like the train is going off the tracks or your team can’t accomplish it’s objectives, then you need to be able to delve into that issue and resolve it. But you can’t participate in their rant session; listen, decipher the issue, and then take action.

4. Find time to stay technical.

As an employee, I can tell you that it’s tough to work for a manager that doesn’t understand what you do; don’t become that manager. I can’t stay abreast of every specialized aspect of SQL Server, but I can keep up with the gist of things. I may not be up to speed on the latest and greatest design patterns, but I need to be able to have a conversation with a developer and understand what they’re trying to do. I’ve recently started studying for the MCSA on SQL Server 2012; I haven’t been certified on a platform since SQL Server 7. I feel it’s important to show my guys that I’m trying to stay a technical resource for them, and also encourage them to pursue more knowledge. The expectation in our department is that research is part of our jobs.

I used to dream about being an Microsoft Certified Solutions Master; I put that dream on hold so I could take care of my personal life, and now it looks like I’m walking another path. It doesn’t mean that I can’t be a technical person; I just will have a broader repertoire.

5. Change is hard; get over it.

I just got back from the first week of Model-Netics training which is offered by my employer in a four week series (over four months); one of the first models we talked about was the change curve, which looks something like this:

The idea is that everybody is plodding through life at a certain level of productivity and morale, and then a change occurs (a promotion, a formation of a new department, a new process gets implemented, etc…); suddenly everything is askew, and productivity and morale go sliding down the mountain toward the valley of despair. At some point, acceptance will set it, and if the change is a positive one, productivity and morale should settle in at a new high.

Scholars will note that the change curve is widely used in terms of the 5 stages of grief, but the point of it is that normal acceptance to a change takes time, and a realization that things are different and you’ve got to adjust to the new normal. I went into this management position thinking that I could quickly bounce into doing the things I wanted to do, without realizing that it was going to take some time for me to adjust to my new responsibilities. I also had to balance the productivity and morale issues in my new department (as well as my old one). That realization is the basis for transitioning from a slide into a climb.

It’s been an interesting first year, and I’m looking forward to the new challenges ahead. I’ve never worked so hard in my life, but yet I feel like my job is important to me, and at the end of the day I can put it down and focus on other things. Life is about more than a career.

2012-11-20 by Stuart Ainsworth Professional Development SQLServerPedia Syndication 5