58 Search results

For the term "management".

Changes… #DevOps, #SRE, and #Management

As many of you know, I’ve been slowly changing focus from database administration to DevOps, management, and service operations. Over the last few years, I’ve been heavily involved with migrating our datacenter to a private cloud infrastructure, and focusing on methods to improve the overall reliability and scalability of my company’s service deliverables. I’ve been a bit of an evangelist for organizational changes, and it’s finally official.

On October 1, my job title and responsibilities will officially change from Manager of Database Administration to Senior Manager, System and Network Administration. I think that title’s a bit funny, because I won’t be managing system or networks; our infrastructure is managed by another team, and my team is responsible for applying principles of Site Reliability Engineering to operating our complex business services. Unofficially, we’re calling ourselves Service Reliability Engineering in order to remind ourselves (and others) of our foci:

Identifying issues that impact the reliability of customer facing services;
Tracking and documenting complex relationships between applications used in that delivery; and
Coordinating efforts with other teams responsible for developing and operating those services

The title change itself is a minor issue, but it’s an important distinction to me. It represents a significant shift in my career path. Although I’ve been acting as the IT Operations manager for the last two years, it’s always felt a little odd because I was still known as the DBA manager. With the move to the cloud, most of our administration (like backups, DR, and maintenance) are handled by another group, and we’re responsible for making sure that the applications (all 84 of them) perform appropriately. We’re not coders, but we need to be able to identify coding issues. We’re not network or sys admins, but we need to know how systems work, and be able to propose solutions to scalability issues. We’re not DBA’s, but we need to be able to express data requirements to the new DBA team. In short, we’re an integration point for a loosely coupled set of applications.

I plan to blog more on Service Reliability Engineering in the future, but for now, I’m excited about what’s happening.

2017-09-29 by Stuart Ainsworth Professional Development 0

Using @AnyDo for tasklist management

Trying to stay in the habit of writing, and this seemed like a quick post, so here goes; I’m not really in the habit of writing product reviews, but I’ve found this one to be useful, so I thought I’d share.

Task management is something I’ve always struggled with; I’ve tried various systems from Trello to LeanKit to Kanbanflow, and they’re hard for me to use consistently. At work, I use a homegrown SSRS report connected to our helpdesk system as a kanban board, but it’s clunky for ad-hoc requests. It takes way too many clicks to create a ticket for a simple to-do item like “set up a meeting”.

I recently got an Amazon Echo Dot (and later a Tap), and I was intrigued by the to-do list functionality; suddenly it became quite easy to jot down a quick task for either business or personal work. I just shouted out “Alexa! Add do something awesome to my to-do list”, and was immediately gratified with a task appearing in the Alexa app on my iPhone. Excellent. Except for when I was away from my desk (and my Echo Dot). I could open the Alexa app and add a task item manually, but typing seems so old school. And then I remember, Siri could do reminders too. Guess what? Integration with Any.Do.

Long story short, I can now manage nearly all of my to-do items by voice. If I have a brilliant idea while sitting at my desk, I ask Alexa to note it for me. In the car? Siri’s my friend. The beauty is that they both go to the same repository in Any Do, and I can mark them as completed as I knock them out. The only downside is that the app places them in different lists, but I can view them in one combined list (see screenshots below).

Visibility is only part of the battle; organization is equally important. One of the features that I really like about this product is the “Plan My Day” option. Basically, if you have several tasks scheduled for today, you can run a little wizard to cycle through all of them and decide if they’re really going to get done today (or not), and schedule them accordingly:

I try to keep it to 3 tasks a day; this gives me the flexibility of responding to issues as they come up, and still feeling like I’m getting somewhere. I usually add more tasks as I work, but if I finish with a clean slate (three planned + x unplanned), it’s a good day. Lots more features to explore, including calendar integration, subtasks, and task assignments, but I try to keep it simple. I’ve been pleased with how well the voice integration works, and how natural it is to manage my to-do list now.

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

#DASH2023: Three Things I Learned

Recently attended the 2023 DataDog DASH conference, and it was a lot of fun. This was the first in-person multi-day conference for me in a while (I did crash the PowerBI SQLSaturday Atlanta conference back in February, but attended no sessions and mostly just went to see friends). I had a blast; the conference space was amazing, and the content was thought-provoking. Here’s my key takeaways.:

Take your team to conferences.

I’ve been a manager for over 10 years now, and I’ve struggled to convince upper management to send multiple key individuals to conferences. Thankfully, my director at Grainger is a big believer in education, and not only did he encourage me to send a team, but he also wanted to come as well. It was awesome to have feedback on topics both upstream and downstream. I had team members with a variety of experiences (junior, mid, and senior), and they raised some insightful questions. We split up often, so I still managed to make some new networking contacts but it was good to come back together and discuss new ideas.

Your fires are no worse than anybody else’s fires.

Sometimes being on the production side of the development pipeline you get the feeling that the world is burning and there’s absolutely nothing you can do to save it. While we were at the conference, my slack channels were screaming about several ongoing issues that my team was having to deal with. At times, it’s overwhelming.

But talking to folks at the conference from companies in all types of verticals from health care to automotive to financial to manufacturing, we’re all dealing with the same issues. Changing enterprise systems is hard, and modern development methods often accelerate faster than production systems can respond. Additionally, systems that have been in place for years have often grown connections to other systems in unexpected ways; things break, and they break fast. Observability systems offer hope, but we shouldn’t feel like we’re the only ones struggling with implementing that vision.

AI, AI, AI,AI, AI, AI

Artificial Intelligence and Large Language Models are here. DataDog offers some compelling use cases to accelerate MTTx (Mean Time to Detect, Acknowledge, Respond, Repair, Resolve), but it will take some time to get the plumbing set up for it to provide value. Additionally, users have to be trained on how to do their jobs with a co-pilot. They have to trust the system, and know when to dive deeper than the initial responses. They have to know how to phrase questions in such a way to help the assistant understand them, and they have to understand what the assistant is suggesting. That’s going to take time.

2023-08-05 by Stuart Ainsworth Blogging is FUN! Professional Development 0

Roll With The Punches – #opentowork #sqlfamily #datafam

For a lot of Salesforce employees, January 4, 2023 was not a good day. I was standing in my kitchen, getting my kid ready for school when I got the email at 6:16 AM EST.

Hi Stuart,
As we announced earlier today, we’re reducing our workforce by about 10 percent, mostly over the coming weeks. Unfortunately, as part of this reduction your role is being eliminated.…

Shock. Confusion. Acceptance. Thankfully, the severance package is good, and I have time to find the next opportunity.

I had only recently joined Salesforce (on February 7, 2022) after a lengthy career at Jack Henry. I had big plans. I was going places. I liked my job with Tableau on the CI Infrastructure team, and had been exposed to some great ideas, and had big plans to tackle some interesting challenges this year. In fact, I was already planning on writing a version of this blog post in preparation for the upcoming V2MOM process. One of my values can be summed up with the quote from Mike Tyson:

Plans change. They sometimes shatter like glass. But how do you recover when you’re reeling in pain from something? You go back to the fundamentals.

The fundamentals are those skills you’ve built over the years through practice. They should be automatic in times of crisis. Boxers constantly work on the fundamentals of their craft well before a big fight. They can walk into a ring with big plans, but when the blows start landing and the plans fall apart, what saves them is always going to be how well they can marshal the fundamentals.

As a manager in the technology space looking for my next opportunity, I’m going to sharpen the three following fundamentals:

First, my network of peers is large, and filled with good people. I was frankly overwhelmed by the number of people that reached out to ask how they could help and offered up leads. I am grateful, and it just makes me want to continue to invest more in building relationships.

Second, my technical expertise is T-shaped; I’ve got some in-depth knowledge of database architecture and performance tuning, and I’ve been exposed to a lot of ideas for software deployment across the lifecycle. I’m going to continue to work on some weaker areas (Git, Linux, Powershell) while I search for the right opportunity.

Third, I’m a Work From Home master. I’ve been working from home for the last 17 years of my career. You want a manager who understands how to motivate a remote team and build a remote culture? Boom, I can do it. You need somebody who can set deadlines and expectations around work\life balance? That’s me.

I got this.

If you wanna see what my career looks like, add me on LinkedIn: Stuart Ainsworth | LinkedIn

2023-01-10 by Stuart Ainsworth Blogging is FUN! Professional Development 1

Powershell – parameters & credentials

Just a quick blog; am working on a script that requires credentials to run against a REST API, and a developer wanted to convert that script to use command-line parameters. I built this script (and quick test) to show that the command-line parameters create the same object as the Get-Credential object.

#define command line parameters
param (
    [string] $User,
    [string] $PWordClearText
)
#assign paramter values to appropriate objects, including creating a credential

$PWord = ConvertTo-SecureString -String $PWordClearText -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, $PWord

#Get credential from prompt
$Credential2 = Get-Credential

#compare the two credentials to validate
Compare-Object $Credential2.GetNetworkCredential().Password $Credential.GetNetworkCredential().Password -IncludeEqual

Nothing exciting or in-depth, but this is the foundation for automating a script I wrote to run under specified credentials.

2022-08-24 by Stuart Ainsworth Blogging is FUN! 1

Sending monthly scheduled email from an Azure DevOps query

One of my tasks over the last few years is to keep management and senior management aware of software deployments for our hosted services. This started out as a CAB (Change Advisory Board), but all of our deployments quickly became standard, and it basically became a monthly review of what had happened (which is not what a CAB meeting is supposed to be). I figured a meeting wasn’t necessary, so I was looking for a way to show what we’ve done in an easy to digest method.

The problem is that Azure DevOps doesn’t offer a scheduled email functionality out of the box. There is a Marketplace scheduler that you can use as part of a build, but unfortunately, t didn’t work in our environment for some reason. I stumbled on the concept of Power Automate, but Azure DevOps is a premium connector. However, we do have an Azure subscription, so Logic Apps it is.

Below is the flow that I came up with. At first it seemed relatively straightforward to pull together, but the stumbling block was the fact that the HTML tables are VERY rudimentary. No styling, no hyperlinks, nothing. That’s the reason for the additional variable steps.

The initialize variable state is where I define a string variable to handle the output of the Create HTML Table step. It’s empty, until I set it later (in the Set Variable) step. The Create HTML table was mostly easy, except that I wanted a defined border, and a hyperlink that would allow recipients to click on the link and get to the specific work item.

[ba]https://your_org_here/your_project_here/_queries/edit/{{ID}}[ea]{{ID}}[ca]

The set variable then takes the output of the Create HTML table step, and replaces the placeholders with appropriate HTML tags. In this case, I added a table border, and made a hyperlink out of the ID column.

replace(replace(replace(replace(body('Create_HTML_table'), '<table>', '<table border=10>'), '[ba]', '<a href="'), '[ea]', '">'),'[ca]','</a>')

The email step then uses this variable in the body, and the final product looks something like this:

2021-02-05 by Stuart Ainsworth Something New 0

#DOES20 Reflections

I usually try to write these Three Things I’ve Learned posts at the end of each day of a conference, but this is a little different. This is the first multi-day virtual training event I’ve been to, and because it’s virtual, there’s no travel. Which means my day begins on EDT, and the conference starts (and ends) on PDT. Makes for a very long day.

That being said, I love this conference: DevOps Enterprise Summit 2020 continues to push me to think abstractly about technological problems, and grounds me again in looking at cultural issues within my organization. These are the three things that have resonated with me (so far):

I’ve got to do more to make the pain visible across the organization. Lots of folks have stressed the necessity of communication across teams, disciplines, and to the upper management, and that’s really sticking out to me. I think we’ve done a decent job of complaining, but we haven’t done the best job of proposing better ways of solving problems.
I need to celebrate my team’s victories more. My team works hard, and there are moments when they feel forgotten in the grand scheme of things, particularly when other teams are holding them back. I need to make sure that they realize how much change they’ve promoted, and how far we’ve come as an organization.
Set the Vision, but focus on the first step. A few years ago when I started us on this journey, I laid out a vision, and I need to revisit that. A lot has changed, including both targets we hit, and goals that are no longer on the roadmap. I need to make sure that I frame each step along the way in terms of the value it brings to the service we’re offering.

Virtual conferences are a different kind of fatigue; it’s been rough staying focused. I think I’m going to write another blog post to describe what’s worked for me, and what I’ll do differently in the future.

Back to learning; 3 more hours to go today 🙂

2020-10-14 by Stuart Ainsworth Uncategorized 0

#DOES18 – Wednesday Takeaways

Last day of the DevOps Enterprise Summit 2018, and I had a few aha! moments that really clicked for me.

Jon Hall’s presentation on swarming was a great practical explanation on how to manage swarms. My team needs to be more available to Tier 1 and Tier 2 to swarm on issues and resolve them. It’s not quite the same model as the model Jon presented, but it’s a step.
As an organization, we don’t need a plan so much as we need a set of common principles: commitment to communicate (make work visible to teams, management, customers… etc.), and commitment to best practices in development (SOA, Agile, product not project, etc.). That’s the first step; once we’ve identified those principles, then there needs to be an establishment of processes that reflect those principles.
Uncertainty is good. We don’t need to stay in a particular mode in so much as we need to find the problem and solve quickly.

Keynotes are up, if you want to check them out. Great stuff in there.

2018-10-24 by Stuart Ainsworth Professional Development SQLServerPedia Syndication 0

TIL from Atlanta #AzureDataFest

AZURE DATAFEST

I’ve been meaning to write this post since we wrapped up the event, but life, as usual, gets in the way. Overall, I was very pleased with the whole event; things (for the most part) ran very smoothly. However, in the spirit of continuous learning, here’s a few lessons (in no particular order) for anyone considering hosting an Azure DataFest in the future.

Event Management

We used Sessionize and EventBrite to handle speaker submissions, schedule building, and attendee management. Both tools worked great, but both are a little pricey (Sessionize charges $250 for the event, and EventBrite added a $3.54 fee to every ticket sold). The benefit is that it was very easy to generate a professional looking schedule, review abstracts, and manage attendees (from fee collection to attendance rosters). The one downside is that the tools don’t integrate (no way to easily export speakers into Eventbrite), and we really need a central website for people to hit rather than each individual tool. I also had a small issue where some attendee badges didn’t print; that was probably user error.

Sponsor Expectations

I should have added company names to each attendee badge to make it easier for them to see what company attendees were from when talking.
I need to explain the email\contact information privacy policies better. Some sponsors wanted to get more contacts to add to their mailing list. May need to borrow a page from the SQLSaturday playbook and encourage raffles to get information directly from the attendees.
Microsoft SSP’s were on site, and that was a very valuable contribution. Saw lots of hallway conversations with clients and Microsoft; that’s rare for SQLSaturdays.
Need to charge more for sponsorships in general; we had a flat rate of $500, which doesn’t go a long way toward building a community. Also, I need to provide more structure over what’s included in a sponsorship; we had a couple of sponsors which had 5 or 6 team members show up. Since food was included in their sponsorship, that literally ate up most of the profit from their sponsorship.
Need to find ways to encourage relationships between speakers and sponsors; speaker dinners or vendor parties?

Attendee Management

Generally, went well. Food portions were about right, fee was right for a two day affair, and we had very few snacks and\or drinks left over.
Would love to go as paperless as possible; however, I think people like having SWAG bags. Maybe provide them with an empty bag, and tell them SWAG is available at sponsor tables?
Stickers were a HIT!
Very different crowd than a SQLSaturday. In fact, during opening session, only a few people had heard of SQLSaturday or AtlantaMDF. Need to do a better job of evangelizing both of those, while recognizing that this is a crowd that may not want to give up their weekend.
Pretty sizable fall-off on Friday (the second day). May need to do Monday-Tuesday to see if we do a better job of retaining folks.

Speaker Management

As noted above, Sessionize worked great for speaker management. Abstracts were easy to receive and review, and building a schedule was a snap.
Need to be more up-front about the volunteer nature of this conference. We had a few people that misunderstood, and submitted from abroad, and then inquired about travel reimbursement. It was cleared up over a few emails, but I should have headed that conversation off earlier.
I had a speaker withdraw because we charged $50 to attend the two-day conference; they felt that didn’t fit as a “community” event, since most community events should be free to the consumer (or offer an optional lunch, like SQLSaturday does). I get the point, but in practical terms, that’s tough to do with a new event. No event is free; just different people (sponsors) pick up the tab. We’ll continue to work on this, but ADF may always have a small fee associated with it.
Most sessions had speakers sitting in the audience. I haven’t seen that happen at SQLSaturday’s in a long time, so I’m hoping that people learned as much as they gave.

Logistics

Facility was great, but room capacity != seating arrangement. I had to steal chairs from sponsors, and actually order more chairs on the first day to eliminate standing room only.
I loved having the plenary (everybody in one room) sessions at the start; really need to do one at the end, and then do a wrapup.
I could have saved some funds on table linens. The caterer brought their own, and they weren’t really necessary for the check in tables.
We had a few technical glitches, so we need to make sure we keep the facility staff around next year. They went to lunch and weren’t back in time for the afternoon session, so those were a little rough (maybe promise them free lunch next year?).

2018-09-17 by Stuart Ainsworth Conferences Professional Development SQLServerPedia Syndication 0