In my first post, I reference that by the end of your first 30 days you should have a 90-day plan of things to tackle at your job and how to proceed with the company. I believe this is vital to establishing your career at the company. I have gone into companies and just got lost in the shuffle by not being assertive enough and making my presence known and getting into the weeds. I’ve also done the opposite and became a well-respected employee that people felt was approachable and valued team member. Also, note as you are making all these improvements keep metrics and documentation to show your manager at the end of this time period.
Also, if you haven’t made it through everything, I outlined in the first post for the first 30 days don’t panic it is OK. Sometimes things take longer after different companies. I didn’t’ get through all that stuff at each company in my first 30 days. I did successfully at two of four. Currently, I’m not completely through it so I’ve just rolling it forward the half-completed stuff and moving forward with my plan.
Days 31 – 60*
By now you have a sense of how the team works and how teams work with your team. The flow of processes and maybe the not flow of processes. You’ve had time to access the system with the tools mentioned in the first blog post and have a list of things to fix and may not even know where to begin with that list. In a couple of the companies, I went to in the last four years the list of things that needed working on was massive. In one company in particular the development team and administrative team didn’t work together and made my job difficult. I wasn’t there long. So where should you begin? There are three aspects I suggest taking a look at one is of course strictly the technical database-related work you were hired for, the second would be documentation processes and finding ways to improve them, and the third is figure out the one thing about your new job you are the weakest at and go out get educated on it. Below I’ll give examples of some of the things I did at some of the various jobs, these won’t be limited to my last four in four years.
Technical
This is the part where I go through a cleanup anything I find that needs to be configured, set up to run that I want to collect data on, etc. So, for example:
- For documentation purposes, I highly recommend using PowerShell to run Glenn Alan Berry’s diagnostic queries in notebooks against every server to get a snapshot of everything. I’ll follow up with a blog post with a script on how to do that.
- I would setup sp_BlitzIndex to log to table at midnight every night. I have a trick where I check the startup time where I stored it the night before and only keep last night if the server restarted. So, I’ll follow up with a blog for this script as well. This will give you future data to look at what indexes are actually being used. And for those tables that have no indexes except maybe that unigueidentifier that the consultants put on every table because of replication but didn’t make it a ROWGUID so then a column name rowguid was added as well onto the tables that were replicated (oy!) and what about all those floats, and then when I said something about that decimal (18, 8) (oy, oy, oy).
- Setup some performance monitoring with perfmon if they don’t already have a tool. David Klee (b | t) has it completely documented on how to make sure it restarts when the server comes back up and cleans itself up right here. On GitHub, he has a project to import the perfmon to SQL so you can do whatever you want with the data.
- All those sp_configure settings, missing patches, trace flags, power plans, etc. that sp_blitz and dbachecks pointed that you found in your first thirty days you can prioritize those and tackle the most important ones and chart your progress. This is going to repeated in each section because unless you are going into a company that has well experienced DBAs for years there will plenty of these things to suggest doing and help write code to maintain.
- One company had a month end process that just died when it ran. They had reached a tipping point with too much data, well not really. They had too many indexes. Like 12,000 DTA indexes. Holy smokes!!!!!! So, I dropped every index that was not being used and wrote a script to strip out every include column in all the DTA indexes. Split the data into multiple files and the data and indexes into separate file groups. Next month in customers were happy. Boss was happy. Still contacts me wanting to do consulting work for him.
Ok, I think that’s enough on the technical side for 30 days and well a couple whooper of examples.
Processes
This is the part where we start getting more involved in the company cross teams. I once got told at job I didn’t do this enough, although I worked on the projects I was assigned, but didn’t involve collaboration with other teams. But to make an impact at a company at some companies to get certain promotions you have to be known outside your team. no matter how skilled you are at your job.
- The best way I know to get involved in the processes of teams is to make sure you get invited to meetings involving teams that do any development work against the databases. You will need to collaborate with them. You will be troubleshooting issues with them. So, it’s best to get in there early and hear what is going on, even if you have no idea what they are talking about when it comes to the features they are building in the app. That will come with time.
- At a minimum in your team meetings, start contributing at least one idea in each meeting. Don’t be shy you have knowledge that is valuable, you were hired for that knowledge, use it and speak up.
- Now we start getting involved in processes. For example, I noticed at one of companies that they seem to just develop new features and not look at the current performance of the system. So, I asked for them to insert into each sprint for someone to review the top one or two queries performance wise and improve it. They work with one of the members on the database team, it could be one of us that does it and then hands back to development for verification. However, that process works for your company. But regular performance improvements should be being evaluated, because as data gets added to the system things change, statistics, index being needed, etc.
- Another example, at one company the developers designed the tables, remember those consultants I mentioned previous (oy!). But those were two separate companies. Make sure someone is designing tables that understands the internals of SQL.
- Make sure there are code reviews if there aren’t any already.
- Introduce the concept of source control even for the database schema. Ummm, explain to your company why the “feature” where the customer basically has SSMS in the app to change the column widths and types and add columns, so all your databases are different is bad. Entity value tables, folks.
Just a few examples of processes that cross teams that be discussed and worked on.
Professional Development
Identify your weakest area that your company needs you proficient in. Yes, they hired you for what you are good at, but we all have more to learn, unless you think you are the overlord of SQL Server. Just a list, this will overlap to your other sections of days.
- PowerShell
- Azure
- High Availability
- My new one, Power BI, coming for you pre-con at Summit
Days 61 – 90
- At this stage you are ready to tackle bigger things. When you see an issue dive deep into and find the root cause and give solutions, identify problems you see in processes and provide feedback on how to improve those. Document any of these findings and keep contributing to the company’s documentation and meetings. If you are in lead position start planning projects the team can work on and coordinate with your boss on priorities and what projects, they had on the books to work on.
- At this point too, I would spread out some follow up 1:1 with your team members and get a gauge for how they feel things are going with you being on the team. Ask them to be honest when giving you feedback. You can even stretch this out past your department to some of the teams you have been working with. You need to make sure you are forming good relationships from the beginning.
- And oh, did you finish all your onboarding training. It’s usually all due by now. And do a 90-day review with your boss and show him all the things you have done. Continue down your professional development path and knocking off those little things on your long list.
Days 91-120
- Time to really make this job yours. Take ownership or charge or command or what word suits you but take responsibility for things now.
- Start getting people to implement any necessary changes to processes that are needed. Get them well documented. This may stretch out past the 120 days, but you start the discussions now. For example, coming up with coding standards, or a new security strategy. The fact that people just randomly log into production using SSMS and kick off 10-hour processes is not cool with me.
- Set your goals for yourself for the next 90 days, this part of your six-month plan. What you want to accomplish for yourself technically, process wise, and professional development wise. Put those milestones for projects on there. Make things realistic, keep your work life balance.
- Keep you focus on what’s best for the company along with what advances your career at the same time. They should go together.
Summary
- You want to knock off the little things you found in your assessment.
- Find things you can improve from the technical side.
- Improve processes the company has.
- Develop professionally on weakest area.
- Become involved across teams.
- Set personal goals and start working on projects.
- Make the position your own and take ownership of it.
- Meet with team members to find out how they feel you are doing and your boss.
- Document everything.
- Develop the next six-month plan.
Please leave comments and your own suggestions.
* Technically we already have done our first 30 days
