Stacks on Stacks

The Serverless Ecosystem Blog by Stackery.

Posts on Company and Culture

Start Now: What My New Job Taught Me About Inclusivity
Farrah Campbell

Farrah Campbell | July 18, 2018

Start Now: What My New Job Taught Me About Inclusivity

A few months ago, I was invited to be a part of a documentary - The Chasing Grace Project. The project exists to raise awareness around the presence of women in tech, because the truth is, you can’t be what you can’t see. I certainly didn’t start my career in tech, and it was a transition that didn’t feel accessible until I started to meet people who were in that space.

Since then, I’ve volunteered with PDX Women in Tech and Techfest NW, worked at multiple tech companies, and met countless people in this industry who’ve changed my entire life for the better both professionally and personally.

I guess you could say supporting more women entering tech is something I’m passionate about.

So when my last company, Reflect, was acquired by Puppet, there was no question about what my priorities would be while looking for my next position. After being offered some incredible positions at incredible companies, I stayed connected to what I wanted in the next company I joined. Above all, I knew I wanted the following three things:

A Smaller Team

The people hired at the beginning set the tone for the rest of a company’s growth, and growing remarkable company cultures is something I love doing.

A Place Where I Can Grow and Feel Respected

I value leadership that supports personal growth as much as what you can do for them right now. The first two leaders that I worked with in Tech challenged me to learn what I didn’t know yet. Even things like learning to write a bit of code or filing bug tickets after testing a product update. I had never been in an environment that unquestionably supported me in the process of pushing those boundaries to go from “a person who does not X” to “a person who does X”. The feeling was exhilarating and I now know that I need this in order to be successful.

A Company That Supports Diversity and Inclusion

Now, that last one can be sticky. We all know there are more than a few companies out there, run mostly by men, who treat diversity as a number they need to hit on their spreadsheet. It’s not about changing the statistics or opportunities long-term for them - it’s one more reason to say, “Look at me!”. Because the thing is, it’s hard to build a diverse team if it’s not diverse from the start. We see companies struggling to keep female talent for a reason. Women leave tech at twice the rate of men.

So I’m more than a little wary of companies that claim inclusive policies, especially if it’s a new initiative for an older company. I had three phenomenal opportunities, and there was no way I could say no to Stackery. Why?

Stackery was a team of 10 when I started - including four women of which three were engineers. That number spoke volumes to me, because it meant not only did they prove they valued diversity from day one, but it meant it was possible from day one.

They were taking inclusivity seriously, doing the right thing from the start. They didn’t make excuses. They didn’t just hire their friends. It was a concentrated effort to have a diverse team from day one. While I love every team I’ve been on and love the people I’ve worked with, Stackery’s commitment to inclusive hiring practices says something to me about them as leaders.

The reality is, the employees who are there early on are the ones who will lead the way, especially regarding culture. Being able to walk in and know that I wouldn’t have to fight to have an opinion or be compensated fairly was validating. I felt like I would have real support from the get go, and that’s exactly what’s happened.

So to all the companies who say, “But we didn’t get any women applicants” or “We couldn’t find any women who were qualified”, I say this - You’re not looking hard enough.

I challenge you to post your job postings on sites geared for diversity, to work with code schools who prioritize women, to create a culture that is actually inclusive and not simply stating that it is important to you.

So far, Stackery has been amazing. I’m learning a ton, work/life balance isn’t something that just gets mentioned in a job posting, and everyone’s doors are opened. I look forward to continuing to grow with this humble, talented team.

Unexpected Lessons from Startup Life
Nicole Blystone

Nicole Blystone | June 28, 2018

Unexpected Lessons from Startup Life

It probably goes without saying that working at a startup is exciting. Things move quickly, people are passionate, and it’s easy to see the impact of your daily work. Everyone feels invested, and it doesn’t feel like a big deal to put in extra hours, go through emails or bug fixes on weekends, or to do what needs to be done to hit those milestones.

But here’s the thing-it is a big deal.

One of the things that most startups tout is a great benefits plan. Flexible hours! A well stocked selection of snacks! Awesome vacation policies! A benefit that should also been included in this list (but that too often slips through the cracks) is work/life balance. Yes, it’s important to meet deadlines, but it’s also important not to burn out. I know I do my best work when I’m rested and refreshed. You probably do too. So how can individuals–and companies–promote a healthy work/life balance?

Unplug: You may not have strict work hours. You may pride yourself on your fast response time to emails. You may have days where you take calls from home outside of your usual 9-5. That’s all fine. Try to set aside time, though, where you don’t check your emails, don’t take work phone calls, and don’t open up that work computer. Taking time away from your daily job duties helps your brain reset, and it can open up your mind to other ways of problem solving since you’re not letting yourself get entrenched 24 hours a day in whatever you’re working on.

Use that vacation time: It can be hard to want to tear yourself away from the projects you’re working on, but employers offer vacation for a reason–so use it. Whether it’s a long weekend, a trip to a place you’ve always wanted to visit, or some time to stay home and hang with friends and family, taking time off helps you recharge. Staying fresh always helps you to stay enthusiastic, creative, and energized about what you do day in and day out.

Lead by example: It sounds great to encourage people to balance their life with their work and to take time off, but if no one ever actually takes time off and people spend their nights and weekends working, then the point is moot. If you’re in a management position, it’s especially important to set an example by taking time off when you need it and not responding to emails 24 hours a day (as tempting as that may be). If you do it, the people around you will see that as not only the norm but the expectation. Even if you’re not in a management position, you can still set an example for the rest of your team and coworkers by creating the expectation that you value your time outside of work so that you can enjoy your time at work.

It’s awesome to be excited about your work–and it’s even better to stay that way. Making sure you take time away from the office, shutting off your screens, and taking care of yourself are all important ways to stay happy at work. You are one of your company’s most important assets, after all.

Looking for a place that values work-life balance? Check out Stackery - we’re hiring.

Finding the Right Fit
Anna Yovandich

Anna Yovandich | April 23, 2018

Finding the Right Fit

Before joining Stackery, I spent 10 years as a frontend engineer at digital agencies, building a spectrum of client projects. Though the work was challenging, I was exhausted and unfulfilled by rushed project cycles, marathon meetings, and disposable output. Fortunately, what I needed to do finally became clear: quit.

It was time for some serious self-care and to journey into unchartered waters. Identifying positive and negative work experiences shed light on new goals and priorities. I would find a small and focused product team – building tools that serve real needs, with talented and inclusive people who enjoy their work and their lives.

After some introspective time off to renew my focus, I moved to Portland and discovered Stackery.

I joined Stackery in September 2017 as the fifth team member. Right away, I was contributing substantially to the codebase and sharing significant ownership of the first release. Trust and transparency were paramount from day one, as I began making sweeping functional changes and architecture decisions.

Our team has doubled since then and we continue to operate with a lean and autonomous approach – powered by the mantra: “Ask for forgiveness, not permission” (thank you Grace Hopper). We begin each week with a planning meeting to define features, fixes, and improvements – then we get to work solving challenging problems and building functionality. By mid-week, we check-in to discuss progress, set backs, and discoveries. On Friday afternoon, we have informal demos and share our collective progress to cap-off the week.

Encouraging a healthy work life balance is important to Stackery’s culture. I have experienced the pervasive expectations entrenched in tech culture that violate work-life balance – resulting in self-neglect and diminished quality of life. Our team discourages overwork and behaviors that result in burn out. The leadership at Stackery have established policies and practices to support harmonious, healthy lives. We have the freedom to adjust our workday, work from home, and take time off as needed – a formula that fuels our best work.

Meaningful work, shared ownership, and work-life balance have been critical to restoring energy and purpose in my career. In making the leap from client-driven work to a startup, I discovered that these are the elements I need to thrive professionally. If our work and environment appeal to you, we’re hiring!

Diversity Tips for Startups
Sam Goldstein

Sam Goldstein | April 05, 2018

Diversity Tips for Startups

Originally published on

It’s no secret that tech has a diversity problem and over the last several years there are an increasing number of tech companies working to improve this. There are great resources online about how to approach diversity and inclusion, for example which provides recommendations for building an effective Diversity & Inclusion (D&I) program. However, a lot of the information is geared towards large companies. This makes it challenging for early stage companies to find actionable advice on inclusion and diversity. Over my career I’ve worked at a variety of software companies ranging from 3 to 1200 people and I’ve seen a lot of successful and unsuccessful attempts at D&I in that time. In my current role, leading an early-stage product engineering team at Stackery, we’re building inclusiveness into our company from the earliest stages. So how should a small startup approach recruiting and retaining a diverse team? How do we create a company environment where people of all genders and backgrounds will feel empowered and excel? Here are some of the practices that are most relevant to leaders at early-stage companies:

1. Start Early

When you’re starting a company from scratch you have to prioritize constantly. You’re building a product, finding customers, courting investors, hiring a team, providing customer support, looking for offices, doing taxes, writing docs. It’s easy to convince yourself diversity can wait. A lot of the best practices (e.g. develop an effective employee handbook) don’t really make sense at an early stage when you’re focused on recruiting your first few employees. However, two of the most important responsibilities of every startup leadership team are to hire a strong team and build a strong company culture. You should be focused on these priorities from the earliest stages of your company, and these two areas, hiring and company culture, are where it makes the most sense for startup leaders to focus their diversity and inclusion efforts.

2. Rewrite Your Job Postings

One effective way to attract more diverse applicants is to look closely at the language in your job posting. The way you present your company and team will have a big impact on who applies. Avoid using language that tends to skew the applicant pool male, like overemphasis on how hard your technical problems are or how aggressively you pursue your goals. An effective technique is to describe the team environment, the company culture, and the technical stack. Talk about how you work together and what you value. Every applicant is interested in what the day to day environment will be like, and this takes on additional importance for individuals who don’t fit the typical white male programmer mold.

Avoid describing your ideal candidate or listing requirements. This encourages many potential applicants to disqualify themselves. Candidates used to having people consistently assume they’re “not that technical” (which is very common for underrepresented candidates) are even more likely to skip past your posting and move on. I’ve found it’s useful to explicitly encourage candidates to apply, even if they’re not sure they’re qualified.

3. Plan Your Interview Process

A big part of encouraging inclusiveness and diversity is discussing it with your team. Planning an interview is one perfect opportunity to do this. Communicate why D&I is important to you and the company, and how that factors into your hiring practices. Your team should be discussing what’s being assessed in each part of the interview process, since without a shared understanding of the criteria for the hiring decision you’ll be relying primarily on unconscious bias. Make sure you’re coaching your team to avoid vague statements when giving feedback. Statements like “wouldn’t fit in” or “doesn’t seem that technical” often mask unconscious biases. Make sure your team grounds their feedback in concrete observations (e.g. “was able to implement the program, but struggled to implement optimization X,” “interrupted and talked over me repeatedly”). Encourage your team to ask themselves “what does this person bring that we don’t already have?” and “how would this person add to our company culture?” A group with diverse skills, strengths, and weaknesses will be more resilient than one where everyone shares similar strengths and blind spots.

Structure your interview process to avoid putting candidates on the spot. Interviews are stressful for the candidates and different people show stress in different ways. Your goal is to assess whether the candidate will succeed in the role, not whether they speak eloquently under pressure while discussing CS 101 concepts with a whiteboard. Many people will get flustered and freeze up in these situations. Does this mean they’re bad programmers? No, it doesn’t. In addition, when you consider societal factors like women being perceived as “pushy” instead of “confident” when they strongly state an opinion, it is even more important to think through the way you structure interactions in the interview process. Ideally you should be telling the candidate what to expect and how they should prepare so they can put their best foot forward throughout your process.

4. Plan Inclusive Activities

There’s a lot of data which shows that underrepresented people leave the software industry at higher rates than white males. Why? A lot of it boils down to tiny things that happen every day that indicate to an employee that they don’t belong or don’t fit in. This is why creating an inclusive culture and work environment is a critical part of promoting diversity in your company. One thing that many young companies get wrong is planning team-building exercises and social activities which unintentionally make some employees feel excluded. Look for activities that can be enjoyed by individuals with a wide range of physical abilities, personalities, ages, ethnicities, religions, and sexual orientations. Avoid highly physical activities which some people can’t participate in. Avoid venues that have a likelihood of making anyone feel unsafe or uncomfortable. Minimize off-hours activities which may be challenging for employees with children or other caregiver responsibilities. Make sure that if alcohol is available it isn’t the primary focus and consider the impact on employees who have experienced addiction. Even if everyone on your current team is really into paintball and brewskis, the effort you put into ensuring work-related activities are inclusive will help you attract and retain diverse individuals.

5. Talk About Diversity & Inclusion

One of the first rules of management is that if something is important, talk about it a lot. People look to their leaders for cues on what they should care about and to understand what’s valued by the company. One-on-one meetings are an excellent opportunity to emphasize the importance you place on building an inclusive environment. Ask for feedback and suggestions. Explain why diversity and inclusion matter to you. Encourage employees to share with you (or other leaders) if and when they encounter uncomfortable situations. Keep in mind that many employees may feel uncomfortable sharing situations where they felt excluded or unwelcome for fear of being ostracized or further excluded, so it’s important to build a strong foundation of trust, and emphasize that any concerns they do share will be handled thoughtfully. Meetings related to hiring and team activities also provide great opportunities to provide updates on steps you’re taking to promote D&I, to solicit input from your team members, and to reiterate the importance of building a strong and welcoming company culture.

Starting Inclusively

At Stackery, our leadership team made the decision to emphasize inclusiveness from day one. We believe this is not only the right thing to do, but that it makes us a stronger team. It is a core component of our strategy for building a successful growth business. We’re striving to be a company where people of every flavor can see people like themselves playing important roles and succeeding.

Leaders at startups today have the opportunity to sidestep the diversity problems that plague the majority of tech companies. There’s more awareness and useful info available than ever before on how to solve tech’s diversity problems. It won’t happen overnight. It will require the hard work of many people over many years. But, if you’re in a leadership role at an early stage company you have the potential to avoid the all-too-common situation, where you wake up one morning to realize you’re a company of 50 or 100 or 250 white men with a diversity problem. Instead you can build intentionally towards a better future where people of all shades, shapes, and backgrounds can feel welcome, contribute in meaningful ways, and achieve incredible results. I hope you’ll find these tips helpful for encouraging inclusion and diversity at your startup.

How Do You Know What Customers Want?
Susan Little

Susan Little | March 29, 2018

How Do You Know What Customers Want?

Now that serverless technology enables building and releasing applications without spending precious time coordinating infrastructure changes, enterprises in particular are finding it easier to deliver a stream of innovative features, updates and products to market faster. And while Stackery is developing a product to uniquely solve the operational challenges serverless brings to enterprises, we've often wondered how do you capture what's on your customer's mind amidst all of this rapid development?

Do you know what your customers are really passionate about? What truly keeps them up at night? We probably won't know for sure until we hear the passion in their voices as they talk about their problems.

That is why I'm taking a closer look at what a Customer Advisory Group – where a group of customers advise you on topics ranging from industry trends, business priorities and product direction – can do to provide even better insight into what customers want.

I've had the opportunity to start and lead Customer Advisory Groups and I've found that engaging key customers in a more structured approach can go a long way in building a strong loyal customer and learning more about what is actually important to them.

Since serverless technology enables you to rapidly prototype new product innovations, including multiple directions, one of the greatest benefits of a Customer Adisory Group is to share these prototypes for validation. It’s a great way to get early and quick feedback on your product from your customers.

Additional benefits of a Customer Advisory Group include:

  • Direct, unfiltered, and candid feedback on all aspects of how your company engages within your marketplace – your products, people, and services
  • Early warnings of shifts in customer/market requirements and emerging opportunities
  • New Product Development feedback that can drive innovation
  • Critical insights into both the obvious and the below-the-surface problems customers may experience
  • Intelligence on competitors' tactics and strategies - what's working and what's not

I've found the key to success in setting up a program is to define your mission, identify the benefits to your customers and determine the meeting cadence and follow up. Equally as important is to identify who might be the best fit in an advisory role. Look for leaders within your customer's organizations who are willing to express their point of view and also represent the views of other customers.

Here are three important steps in starting a program:

1. Define your mission

You'll need to gather input from your internal stakeholders and craft a mission for the group. Describing your mission helps explain the group's purpose to your customers and it can also help to set expectations internally.

Creating a mission is helpful to customers and your internal teams:

2. Explain what's in it for your customer

It is important to explain to your customer how they will benefit from being your advisor since they are carving out valuable time from their busy schedule. Often times you might be hesitant to ask too much of your customers because you don't want to bother them, however, it's important to remember your customer's success is directly tied to your success – so they will more than likely be interested in joining forces with you.

Highlighting the key benefits will inspire customers to join the group:

3. Get Buy-In

It's important for your customer to understand what is expected of them. Ideally, you'll have face-to-face sessions in addition to virtual sessions. Hosting these events is a great way to give back to your Customer Advisory Group - customers love it because it's a great way to meet their peers and discuss business challenges in person.

The cadence of the meetings can be flexible – I've found Customer Advisors willing to meet more often to provide input into the product development process. This is helpful with the accelerated development enabled by serverless technology.

Sharing expectations builds buy-in, faster:

Lastly, creating and distributing a Customer Advisory Group meeting summary is important so contributions have been captured and expectations are set for any follow up items.


It is exciting to see the benefits of serverless technology and how Stackery is helping enterprises find an easier way to predictably spin up new environments, automate the build and deploy process, and have operational control and a line of sight into the health of their serverless applications. By adding a Customer Advisory Group to the mix of this rapid product delivery cadence means we can truly delight our customers.

If you are interested in joining our Customer Advisory Group, please feel free to reach out to me at:

The People Side of Serverless Adoption
Nate Taggart

Nate Taggart | August 17, 2017

The People Side of Serverless Adoption

Making the technology transition to serverless architecture is a frequent topic these days. Less frequently discussed is the human component of this change, but it’s an equally important topic. Aligning your organization’s people to your technology transition is a critical component in a successful serverless strategy.

Preparing for change

Let’s face it, change can be uncomfortable. With any technology change, in particular, there’s an underlying expectation that your teams learn new skills, step out of their comfort zones, risk failure and embarrassment, and change their existing workflows and dynamics. That’s a lot to ask.

While the technology transition may be well-justified by significant organizational benefits – dramatic infrastructure cost savings, improved scalability and operational efficiencies – these benefits may mean very little in the day-to-day work of individual developers on your staff.

Ideally, the human transition to serverless begins before the technological shift, by preparing your team for the change. Some companies who have been especially successful in their transition started by creating a serverless advocacy group in advance of any implementation. The serverless advocacy group is generally composed of front-line practitioners (developers, ops, security, etc) from across the organization. Their role is to 1) identify low-risk opportunities for serverless usage across the technology stack, 2) become serverless advocates in their respective teams (educating and building enthusiasm across the company), and 3) collecting feedback and concerns from their teams and working with the rest of the advocacy group to create org-wide best practices to make the transition easier for everyone.

Best (people) practices

Serverless technology is still emerging. Of course, this means that the best practices, processes, patterns, and tools are also still emerging. Surfacing the concerns from your organization is one of the most effective ways to ensure that your transition to serverless goes smoothly. Various stakeholders across the enterprise are going to be able to identify a variety of risks and techniques to improve your serverless adoption. The serverless advocacy group can be a hub where risks can be addressed and best practices can be shared quickly throughout the organization.

A commonly identified concern is that serverless will give up a lot of visibility and control over your applications. For example, many teams may be relying on New Relic for application performance management, and will lose this tool in serverless applications. Instead of ignoring this need, introducing a replacement APM solution (like IOPipe) can alleviate a lot of the reluctance to embrace a serverless architecture, while simultaneously shortening the learning curve across the company.

Related concerns may be a lack of understanding of the new architecture (Stackery’s architecture design canvas can help!), uncertainty around building automated release pipelines for serverless (another key advantage of Stackery), finding application testing methodologies, unfamiliar security models, and how operational responsibility for these applications should be organized. Each of these can be addressed (and the solutions may vary from company to company), but they will be solved much more quickly when there are people specifically identified and assigned with managing these risks.

Process iteration

As with all new processes, expect an ongoing need to learn and iterate. Over time the serverless ecosystem will evolve and patterns will emerge, but until then be prepared to embrace iteration during your serverless adoption.

By identifying people responsible for shepherding the changes and spreading awareness of the risks and techniques to address them, you’ll be well positioned for a successful transition toward serverless technology. But more importantly, you’ll be including the success of your people as a component measurement of the success of your change strategy.

Marital Counseling: Ops and Dev
Nate Taggart

Nate Taggart | February 24, 2017

Marital Counseling: Ops and Dev

For the sake of simplicity, let’s ignore the idea of DevOps for a minute, and, to use an analogy, talk about Development and Operations as two partners in a marriage. Like all marriages, this one started happily.

Development has a special set of skills that it brings to the relationship. They are often on the front line of requests from other teams, like Product and maybe Sales and Marketing. They might spend hours perfecting a design implementation or weeks on a major feature overhaul requested by Sales. In a sense, they thrive in change.

Operations, on the other hand, is focused on the very real and practical need to provide reliability and predictability. They focus on long-term needs and, in many ways, safeguard the reputation of the business. They are stewards of stability and bear the burden of responsibility when things go wrong. Which, in a sense, is why sometimes this marriage goes a little sour.

Marital Strife

Development’s very real need to implement change can often run against the grain of Operations equally very real need to promote stasis. To step outside of the analogy, this can lead to very real feelings of discomfort for the humans behind these teams.

One of the common points of conflict in marriage arises when partners have different definitions of success. Perhaps one partner feels loved with physical affection, while another prefers to hear words of affirmation. This difference in understanding of success can create division in partners, just as it can create division between teams.

If Operations is defining success in terms of metrics like uptime, error rate, and end-user performance, while Development defines it with product velocity, time-to-resolution, and bug backlog, real differences can emerge in expectations between teams.

Relationships can also suffer from imbalances. For example, maybe one partner feels like they’re contributing a lot to the family’s finances, while another partner is making a big contribution by maintaining the household. In healthy relationships, this works great as both partners bring complimentary skills to each other.

Sometimes, though, these differing areas of responsibility may not be appreciated. If one partner feels that they’re solely contributing to the finances and the other is frivelously wasting money, conflict emerges. This type of conflict is common between Development and Operations teams. Poorly-tested changes by Development leading to 3:00am pages for Ops is an imbalance in responsibility. Likewise, slowly provisioned infrastructure resources, delaying Development ship dates and impacting velocity is an imbalance in responsibility.

Marital Counseling

But these differences can be overcome using the same conflict resolution techniques found in marital counseling. While it may not be necessary to sit your Dev and Ops teams down and explore feelings, it is necessary to come together to commonly define success and to identify and remediate imbalances in responsibility. These conversations should happen early and often between these two partner teams.

Another important approach is to redefine each team’s ownership of responsibilities. Is one team shouldering all the pager duty load? Maybe it should be shared. After all, “move fast and break stuff,” sounds a lot better at two in the afternoon, than it does at two in the morning. Companies like PagerDuty and VictorOps have mature alerting offerings which allow for intelligent pager routing based on what breaks. Cluster went down? Page Ops. Service failed? Page Development.

Of course, intelligent paging requires intelligent metric collection, which brings us to the second critical piece of counseling: shared understanding. Operational success and Developmental success should, ideally, share common success metrics. One way to approach this is with internal Service Level Agreements (SLAs). Say, for example, that Operations commits to provisioning new infrastructure within 24 working hours (three typical days) on request from Development. Development, in turn, commits to providing Operations with 40 working hours (or one typical week) advance notice of requests. This method provides two buffer days to accommodate any unexpected exceptions to the plan, while allowing for both teams to get what they need and for both teams to be successful.

Marital Bliss

Like all happy marriages, this approach takes work and communication. The result, two happy teams each contributing to shared success, is worth the effort. Want to get this process started in your organization? A great starting point is to offer an SLA to another team. They just might appreciate it enough to reciprocate.

Breaking into DevOps
Nate Taggart

Nate Taggart | February 15, 2017

Breaking into DevOps

DevOps roles are not only one of the hardest roles to fill, they’re also one of the fastest-growing roles in demand. This is good news if you’re looking to shift your career trajectory, but it also means that the definition of this role is still actively changing. So, before we dig into how to get a DevOps job, let’s focus first on what DevOps is.

Defining DevOps

There are a lot of definition for DevOps, but at Stackery we like to compare DevOps to full-stack engineers. Where a traditional full-stack developer might have expertise in both backend and front-end application development, a DevOps engineer is full-_process._ They have expertise in the entire lifecycle of an application, from architecture to implementation to deployment and upkeep.

If you already have strong developer chops, you’ve probably already begun to tackle some of the application lifecycle duties of a DevOps engineer, including improving integration testing, automating and accelerating deployments, and monitoring system and application health and performance.

Developing Hard Skills

If some of these duties are unfamiliar to you, you’ll want to start here. A great way to familiarize yourself, in a low-risk way, with these skills is to use them on a side project. For once, there’s a great case for over-engineering. Let’s say you maintain a blog. Even though it doesn’t need integration testing, automated deployments, or production-grade application monitoring, it’s a great playground to test and learn without jeopardizing your current role.

Pick a place to start, and then choose an open-source tool and get to work. For example, you could rebuild your blog to run all of the upstream framework tests each time you create a post. By setting up an automated testing workflow, you’ll get hands-on experience with real-world tools and issues. Once you have that working well, move onto another tool or focus on another stage of the application lifecycle, like performance monitoring.

Developing soft skills

While nothing beats hands-on experience with real-world DevOps tools, another great set of skills to develop would be some of the theory and application of how and when to choose a tool for a problem.

One way to master DevOps theory is to learn from the best. Google recently open-sourced their book on scaling their production systems, written by front-line engineers, called Site Reliability Engineering. Even though your side project may not suffer from production-scale issues, you can still learn to identify them and see how the world’s largest site has dealt with theirs.

Create a “Transition Role”

If you’re finding it difficult to make the leap directly into a DevOps role, try creating a “transition role” within your organization. Pick an area of focus and build your reputation as someone with expertise in this area. For example, maybe you become the go-to person for application performance bottlenecks. By picking a specialty, you can start to re-brand yourself as a pseudo-DevOps, even if you don’t have the official title (which can be varied anyway: Site Reliability Engineer, DevOps Engineer, Systems Engineer, Automation Engineer… the list goes on).

Once you’ve established your reputation as someone doing DevOps work, even without the title, you may find it’s much easier to reapply for the job that you want and make the leap.

Ready to Get Started?

Contact one of our product experts to get started building amazing serverless applications quickly with Stackery.

To Top