Career Advancement for Engineers: Client Success is Your Success

Photo by Rob Peebles

Photo by Rob Peebles

Virtually every professional has dreams of climbing the professional ladder. Engineers are no different.

Making the jump from an engineer working as part of project to a Senior or Lead Engineer is all about broadening your influence and impact across teams and departments internally,or across multiple clients, if your role is client-facing.

Most engineers start off as hands-on doers. We build things, knocking it out no matter what we’re working on. Get ‘er done. Make it go.

If you want to advance your career, you need gain influence beyond your own project work. Here are four ways you can do that.

1. Automate Everything

Great engineers are intuitive by nature. They see problems and they identify remedies quickly. They’re also lazy, and hate to do the same thing over and over. Automate it.

Study your team’s workflow and figure out how you can improve it. If you can, build a tool that adds automation to your workflow, and better yet, your entire team’s, not only will you give your company the gift of additional efficiency, you’ll also gain the respect of your peers.

An improved DevOps workflow will change how your company responds to releases or incidents in the most positive way possible.

2. Develop Best Practices

If there’s one thing every tech-based business can agree on, it’s the fact that downtime is to be avoided at all costs. Not only can unplanned downtime be expensive, it can also negatively impact a client’s brand and reputation.

Take a look at the policies and procedures that are in place within your department. Get creative and develop standards and best practices that save time and money, and more importantly, costly downtime and re-work.

Watch out for “We’ve always done it that way.” That may be the case, but that doesn’t mean you have to continue to do it that way.

3. Broaden Your Perspective

You might be tempted to fully immerse yourself into your work. It’s an understandable desire, but it’s not advisable.

The company you work for is much larger than the project or projects you are working on. Do everything you can to broaden your view of your company and your clients’ businesses. That way, you can better understand their pain points, and find ways to address them.

Web, Ops, or DevOps engineers are often uniquely positioned to see more of the moving parts of an organization than colleagues who work in other parts of the company or team. These individuals know how the sausage is made. And they often have the best opportunity to identify the choke points, or silos that can be broken down.

4. Delight Your Clients

At the end of the day, the better you serve your clients, the more likely you will are to earn more responsibility. People are drawn to success. So bust your tail on each and every assignment. You never know when the right set of eyes will be looking over your shoulder.

Don’t confine yourself to the projects you’re assigned. Take a step back, and try to think “outside the box.” You’ll have many ideas. Some of them won’t be feasible, while others will be great. Brainstorm ways to make your organization more efficient or drive more revenue.

Being proactive about your career instead of reactive will open far more doors than you’ll know what to do with. It’s on you to own this and go after it. Nobody else is going to tell you what to do. It’s how you’ll level up.

Troubleshooting Basics: 4 Steps to a Better DevOps Workflow

No attribution required.

No attribution required.

Troubleshooting technology, specifically production incident troubleshooting, requires an analytical mind. Identifying cause, remediating incidents and automating around these problems in the future is more art than science, and comes largely from experience and not the classroom. Here are 4 steps to guide you through troubleshooting today’s technology and applying DevOps concepts to help smooth the way.

Defining The Problem

Before you start the troubleshooting process, take some time to evaluate how much you know about the incident.

  • Where is the problem you need to solve? Are you sure?
  • What other systems does the one you care about connect to or rely on? Are you sure?
  • Do you have data / documentation / monitoring to show it?
  • Do your tools give you a complete picture?

Make sure you can answer these questions before proceeding. Troubleshooting an unknown error as an independent, isolated issue without context could result in unnecessary churn, more work, and additional or prolonged downtime.

Infrastructure today is complicated. You need to be aware of all the moving parts to find where the issue may lie. This approach to incident troubleshooting gives you a more holistic understanding of the problem.

Using Tools

It’s important to employ the right tools to help you with infrastructure monitoring. Software analytics solutions like Ruxit, Dynatrace and Sensu let you visualize events and data in real-time to measure performance and detect issues. Choose wisely. Your monitoring tool depends largely on your business, your process, and your infrastructure.

Unfortunately, even the best tools have limitations. A developer can’t leave diagnosis entirely up to tools. This is where experience is key. Once detected, you might need to further investigate performance issues to detect the root cause.

  • Is it your service or a third party service causing the issue?
  • Was there new code deployed?
  • Are there any recent environmental changes?
  • How scalable are your tools and apps? Are they running optimally?
  • Does data seem to be missing?

All these scenarios need to be considered and accounted for through automation, with added support from your own investigative efforts.

Showing Your Solution

Once you’ve detected and diagnosed the problem, it’s time to fix it. But remember, fixing a problem isn’t a one and done matter. After you find your solution, it has to be applied and tested in real time, and the knowledge learned documented. There are a few questions you should be asking yourself:

  • Can you reproduce the test results?
  • Does your solution work in different environments?
  • Will the service behave differently after changes take effect?
  • Is this desirable?
  • How is the service performing for real customers?

Your solution should produce positive test results on all tiers of the system, in various environments, while maintaining or improving service quality. Your solution is only successful if everything is running optimally and the end users are happy.

Show your work. This won’t be the last time you see this particular problem. Fix it in such a way that you minimize the chances of it reoccurring, and document it in such a way that if it does, it’s easier and faster to resolve.

  • What did that error message really mean?
  • Did you write it down?
  • Did you write it down where other people can find it?
  • Would some additional automation prevent this issue in the future (Something we have done at Razorfish and Rosetta with our productized offerings for DevOps and Managed Services with AEM, WebSphere Commerce and Hybris on the Cloud)?
  • Did your monitors catch it? Why not?

Tracking your progress when you’re solving an issue with your technology is crucial. This way you can provide the most accurate picture of your solution as a process even after it’s been applied and integrated, and everything is back to normal.

You and other members of the DevOps team will have a storied history of your environment’s challenges, solutions, and impact. You can also better anticipate connected or future performance issues or incidents, and address them proactively.

DevOps is still a new concept. It means different things to different people. But this lean approach to cross-functional development and operations also calls for new thinking. Color outside the pages of outdated textbook procedures to engage all levels and all parts of your technology with a customized combination of automation and expertise as unique your or your client’s business.