Shrinking the Budget

Most of us rarely have to build or manage budgets in our organizations, but almost all of us are affected by the budget process. It’s tempting to ignore budgets and just do your job, but sooner or later you might find yourself arguing for more funding for a project, training, or even hardware.

I ran across a short piece on 10 ways to shrink your IT budget and found it a bit scary. I would bet that many of you have had conversations, or been affected by decisions, that follow some of the advice in the piece. The push for open source, virtualization, hosted (or cloud) migrations, or more can cause stress and anxiety when your job is making sure the servers run without complaints from end users.

I don’t expect that all of these would be followed in a specific organization, but some of these might be proposed to you. What I would recommend is you understand the reasons why, or why not, you might adopt any of these ideas. Certainly the time lost from retraining people or rewriting code can overwhelm the savings for many years, but even seemingly smaller changes, like changing priorities can affect the way your clients and customers view IT. It seems that sometimes budgets get changed to provide a short term view that technology spending is being managed efficiently, only to find out later we will remove all our savings by undoing a poor decision.

I’d suggest that you approach budget issues with transparency and honesty. Take a hard look at your costs and determine what items are really needed, and what items aren’t. However, I’d also urge you to carefully consider whether it’s really valuable to save money by not taking care of your staff. While labor is an expensive part of your IT cost, good staff are worth much more than they cost, often by an order of magnitude.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.0MB) podcast or subscribe to the feed at iTunes and LibSyn.

From Great Idea to End Result

This editorial was originally published on May 5, 2011. It is being republished as Steve is at the PASS Summit.

What’s the time for you IT department to get from great idea to a resulting application? This is a very good piece from CIO magazine that finds many IT departments are seen as too slow. However there are a number of companies that are trying to innovate and find ways to increase the speed at which IT departments can deploy an application and respond to a business need.

One great quote in there is “velocity is more important than perfection”,  which is a tenet that I have found to be very true over the years. It’s not that you throw junk out that isn’t well built or tested, but that you don’t try to meet every possible requirement or handle every little issue. The system has to be secure, handle errors, and meet the basic requirements, but it’s more important to get something done and in production than to have it perform and scale perfectly.

Is that heresy to the developers and DBAs out there? Perhaps, but I think this methodology has to go hand in hand with another mantra I heard fromJason Fried: do more of what works and less of what doesn’t. In this case if a system shows promise and starts to get heavy use, it receives more resources and perhaps gets refactoring in real time, even as it gets enhanced with new ideas.

“You want IT to be in constant test-and-learn mode”, another quote showing that IT needs to be working closely with the business to try ideas, learn from them, and move forward. The Agile style of development applies, and in some sense I think this is the future for the strategic IT department of the future.

For the data professional this means that you must learn to model quickly, and with an eye towards a flexible design that might need to change regularly. We need to understand the businesses we work in better so that we can anticipate how requirements might change.

Management has to buy into the idea that applications will not be perfect, they won’t be polished, and most importantly, they are essentially prototypes that either need to have addition resources spent on enhancements or they should be abandoned quickly. However I think this is a great way to develop internal applications that can provide a nice ROI, and be a more enjoyable way for developers to work.

Steve Jones

Bad Management

Many people know that a good manager can make a huge difference in the productivity of a staff. A bad manager can also lower productivity, but only to an extent. Fear of losing a job, or avoiding punishment can motivate plenty of staff to get work done, even when you have a poor, or even absent, manager.

Some companies don’t value strong management skills much, some do. I think most of us would prefer to work for a company that does, but we don’t always get the choice. That’s one reason why I do promote the idea of branding yourself and ensuring you have other options for employment. The more options you have, and the more demand there is for your staff’s services, the more likely that your company will make an effort to work with, rather than lord over, their employees.

For those of you that are managers, or those that might want to help their manager build some skills, I ran across an interesting story from David Haney on his experiences as a manager at StackOverflow. It’s a good set of principles that I tried to keep in mind as I managed people in the past. For those managers that might not know why their staff leaves, there’s a good warning that good IT staff are in short supply, and companies should make an effort to retain them in various ways.

For many of us in the IT sector, we can provide a strategic advantage for our businesses as we enhance and extend software. Many of us are important insurance that keep systems running, hopefully at a peak level. Bad management can impact the effectiveness of our technology organizations, and it’s silly to accept bad managers. This is something that can be fixed with some training and accountability for the manager, with a little effort. Make a few suggestions, or try to show how a better manager (or style) might help you get more done.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.6MB) podcast or subscribe to the feed at iTunes and LibSyn.

Business Pressures

I know a little something about building and scaling a system on the Internet. While SQLServerCentral isn’t the largest site out there, we’ve had lots of experience with growing a site while trying to manage a business. We were successful at it for years before Redgate Software purchased the site. I’d like to think we’ve continued to run the site successfully and balance the commercial needs with our goal of hosting a world class SQL Server community that educates the community on a daily basis.

I thought back about our history and the way things have gone while reading an article on Github and some of the challenges they have faced they they try to build a business from their (primarily) free service. I certainly hope they succeed as I really like the Github model and only hope their investors are as enlightened and visionary as the founders of Redgate.

There are constant challenges in running a business. No matter how good your intentions, the pressure to break even or turn enough of a profit to survive are always there. At the same time, there is just as much pressure from ethical business owners to keep their customers’ and clients’ expectations and needs in the forefront of their minds as they run their business.

I have struggled with this regularly at SQLServerCentral and still do today. Serving the community while providing value for my boss (or making a profit to pay my salary in the past) are two conflicting goals. I think that things have worked out well, but I am constantly striving to maintain some balance between what is best for all.

I do hope GitHub and many of the low cost services are able to transition and survive as they mature as businesses. Even if many of them can’t continue to provide the same services for free, I hope customers see enough value to pay for some level of service, and the sites survive.

Steve Jones


The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and LibSyn.

Getting IT Out of the Data Center

The subtitle to this article says it all: IT isn’t a monolithic cost sink. I support this idea, though I don’t think it’s always accurate. Some companies just want an IT cost sink, where the data processing infrastructure is a utility. It provides a service that’s requested, technology automates specific processes, and that’s it. Certainly many companies think they do more than this, but in reality, IT is just a utility like power or water in many organizations.

However the article points out that an Information Technology department can be so much more. IT can work with the business, improve processes, even provide strategic advantages over your competitors if you structure your environment to do so and allow it to work.

Building a culture that encourages and promotes collaboration between technical and business people takes work. You need to find and nurture technical people that want to work with other people as much as they want to work with computers. It’s great to have highly skilled technical staffers, but you need to ensure they are willing to use their skills to collaborate with business end users.

You also need business people that are willing to work with the technical developers. They need to be excited, and open minded about technology. They have to be willing to think outside the box, understand the limitations of current platforms, and be excited about building something in an iterative fashion with people whose primary focus is on technical work.

I do believe, and have seen, IT groups dramatically increase the efficiency and effectiveness of an organization, but it takes time, and it requires both sides to commit to work together, in a way that ensures each learns from and compromises with, the other.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.1MB) podcast or subscribe to the feed at iTunes and LibSyn.

Managerial Moneyball

I really enjoyed reading Moneyball. Its a book about baseball and data and how information should be used to choose baseball players for the Oakland As. It’s an interesting approach, one that has rarely been used in the sport in the past, though it is gaining traction. It does seem that this approach has helped the As to high level of success given the constraint of their limited payroll. There’s even a great movie if you don’t want to read the book, but the book is really much better and goes into more detail on data points and how they are used.

The idea of using data to make decisions has been applied to other areas, with “The Moneyball Effect” being talked about in other industries. Recently I also ran across an opinion piece on bad managers that also referenced Moneyball. The piece notes that most people make poor managers. They lack the skills, and more importantly, they really lack those innate qualities that motivate, inspire, and engage employees. Whether you agree with that last part, I think most of you agree that most managers are poorly chosen, trained, and certainly not qualified.

The idea of using data to identify people that would make good managers, and perhaps even move people out of managerial roles. The premise of the piece is really the bad managers make their teams perform worse, so if you’ve got one of the seven-out-of-ten people ill suited to the work, you should move them out of that position. Then identify, promote, train, and support the others to manage your employees and help them to perform at their best.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.3MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

Minimal Meetings

This editorial was originally published on April 24, 2010. It is being re-run as Steve is out of town at the PASS Summit.

I read something the other day that struck me. It’s obvious, but I hadn’t really thought about it in that way before. If you invite nine people to a one hour meeting, then is isn’t a one hour meeting. It’s a ten hour  meeting to the company with all the lost productivity.

That’s a lot of time lost.

Especially if you are meeting with developers or DBAs. They often have code to write, or problems to think about, and embedding them in a meeting for an hour, especially multiple people, can do more damage to your project than a lot of bad code. No wonder there isn’t enough time to do testing?

There’s no good solution, especially since meetings can be productive ways to ensure information is shared in a group. They can help reset everyone to the same view of a project or situation. But you should also look to minimize their impact.

Don’t invite people to meetings if they can read about a decision later, or if they are just getting a status update. A meeting ought to be for people whose job is affected. They need to give input on a decision, or make the decision. Everyone else is just task switching away from their job and losing time that could be put to better use.

It’s tempting to invite all stakeholders, and anyone who might be needed “just in case.” Resist that temptation and let people spend more time actually building software.

Steve Jones

Data Decisions or Instinct?

Most of us that are data professionals think the best way to make decisions is to use data to justify some course of action. We look for patterns in data, some guidance that the information we have will lead us to make the best choice for our organization. Google has talked about making data driven decisions as a part of their success and they think more organizations should do this. Any number of other companies also use data to power their BI systems and dashboards that help their employees make better choices.

That seems in contrast to this piece from the Harvard Business Review that says that great decisions don’t start with data. It talks about using stories and emotions, with a few key facts sprinkled in, to help sell ideas and get decisions made. On one hand I agree that stories help to sell decisions, but I often have found that successful salespeople use this technique to deceive and convince by plucking emotional heartstrings, and using relatively little data.

In my mind, the best way to make decisions is to go with your instincts, but while examining and understanding the data. You can’t discard data, especially when it presents strong patterns. However data can be deceiving when we don’t carefully examine the ways in which it’s put together. An average doesn’t always reflect the actual value of a set of numbers, especially when we don’t also understand the range, standard deviation, and count of values.

We also have to realize where we do and don’t have experience and expertise in some subject. We should certainly look to data to guide us and perhaps even justify our decisions, but we can’t forget that the human brain is still an important part of any computational exercise. We need employees that you use their judgement, in collaboration with data, to make the best decision for our organizations.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at

Great Companies – Spotify

I don’t know anyone at Spotify, nor have I worked there. However when I see descriptions and explanations like this one of how they organize and build their culture, it makes me think they’re doing it right.

Autonomy is important, and it helps motivate people. I need to do more writing here, but for now, check out this video. About 13 minutes long, but interesting.

Top Talent Leaves

Derek Jeter will likely play his entire career with the New York Yankees. LeBron James has already left one team, and might leave another soon. Both are Hall of Fame players that have had extreme success in their chosen professions. They are recognized as some of the most talented players in their sports. Why did one stay and one leave? Probably for a variety of reasons, but it seems more and more that organizations are realizing there is some value in the retention of their players and are trying to find ways to improve their success at retention.

In the business world outside of sports, we have much more freedom to change employers whenever we want. Most of us are glad we have that choice. Sometimes we move on when we don’t want to, but in the majority of cases I think technology workers leave companies because they aren’t happy about something.

There was an article about why the top talent leaves a company and I think it presents a number of issues that many employees experience within their own organizations. People aren’t engaged, respected, valued, challenged, and more. In short, they really don’t like their jobs. Many of the issues are often easy to fix, but only if you could fix two of the major items mentioned (#7 and #10). Those are leadership issues, often systemic ones that occur when upper management doesn’t care about culture or doesn’t make an effort to hire and train good managers.

I don’t know if I’d prefer to see people in technology working only a few jobs during their careers, spending decades at each, or if we are better workers with the exposure to differing environments and businesses. All I know is that I am glad that I’ve had the ability to leave bad jobs in the past, usually because of bad managers.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and Mevio . feed

The Voice of the DBA podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at