Growing Teams using DevX+

Today I want to talk about an engineering model that dives into my experience with software engineering team growth. This is something that I've observed, nurtured and evangelized for years. If I have to give this model a name, I'm going to go with: DevX+. Read on and you'll see why.

Setting the Scene for Software Growth

Let me paint a simplified picture of team growth with DevX+. I'll walk you through the scenario of creating a greenfield software application, starting with one person and methodically growing into a team of four. To start, please put yourself in the following growth scenario...

You are a brilliant software engineer and have developed, in your spare time, an application that uses AI to predict layoffs and publishes warnings and guidance to a website where users pay for the service using a subscription model. It's a fairly complex product.

Phase 1: Release to Production... Dev

With a few unit tests in place, and the confidence of a clown at a funeral, you manually push your ML model, API and website to AWS. Several hours later, you cross your fingers, go to bed and dream about a few hundred subscriptions to supplement your income.

When you wake up you see that your subscription count is off the charts! It's accelerating faster than Flappy Bird. With that, you also see that your inbox is flooded with defects, feature requests and a few requests for their money back. Yahoooooo! and... Yikes!

Phase 2: Adding the X... DevOps

Well, this is a heck-of-a-pickle you've got yourself in. You've got a ton of coding to do and a redeploy to meet demands. A redeploy that's going to take hours of your precious time. Ain't nobody got time for that!

You call up your good friend Anna to help, she is good at the CI-CD stuff and knows AWS infrastructure very well. It seems like a logical fit and separation to help scale this effort. She says she'll help, but for 30% of subscription profits. You counter with 15%. She bites. Whew!

Now you can focus on defects, features and responding to those emails while Anna automates your deployment pipeline and reviews your AWS infrastructure.

Phase 3: Adding to X... DevOpsTest

A few weeks have gone by. You and Anna are making great progress. Ana has built out a decent pipeline for you and now she is focusing on re-architecting your AWS infra to save you money.

But it seems that every step forward puts you one step back. Lack of testing is causing all sorts of pain and managing your customer/stake-holders feedback is VERY time consuming. With a bit of profit in the bank, it's time to bring on another person to help.

You need to make a choice though, should this person focus on testing and quality or product future and community management. Your two largest burdens keeping you from writing code (which of course is your true passion). You choose QA help, because you hate testing and you know it's very time consuming. You do require that this QA person has to automate the majority of the testing though, that way the tests can be embedded in your CI-CD pipeline giving you release confidence.

Phase 4: Continue Adding to X... PO

We've got a serious small business on our hands now... I think you can see where this is going.

What are the next logical steps? It depends on the business, team and product needs and constraints. In my experience it's either another developer to help with development workload (with architecture and scale experience if you need it) or a product owner to help manage your customer, community, stakeholders, product and roadmap. Once you add those roles/passions to the mix, your bases are fairly covered. Continued growth often adds redundant titles (e.g. Dev) with various specialities, until the team becomes 7 plus or minus 2. That brings on another set of challenges that we won't cover here.

In Closing

I'll admit, this is a very rudimentary example of growth and there are a lot of other variables that could impact the use of this DevX+ model. But, for the most part this is how I see it play it out in a fast-break startup. A startup as described above constrained by money, or the start of a great idea in an already existing mega-corporation. If you're lucky, in the mega-corp you might have the resources to put the team together all at once. If you do, what is your high-performing-team composed of if you are limited to 3-4 resources? I know what mine would be. I've seen it play out over and over again over the years. I've observed and worked inside the success of DevX+ and I've also seen struggle and failure when one or more is missing from the Dev-Ops-Test-PO-Architect passions.

Here are few additional points to consider.

• Constructive and strategic addition of a team member, by the team, will get you a very lean and focused team.
• Operations and CICD is expensive and takes time. If you invest in it early you will not regret it, because your team will be empowered to release rapidly.
• What about DevSecOps? Good news! With your CICD pipeline you can move your security scans earlier into your process. That's a great start for continuous security.
• The "X" in DevX+ is a decision and sometimes the order as described above might differ due to skillsets within roles. For example, you could have a Developer who is also great at Ops so you feel those bases are covered at that time. The question then becomes: "Do I have the time to do both things in order to quickly meet the stakeholder needs and not miss opportunity?"

I'd love to know your thoughts about the DevX+ model in the comments below. If you're new here and you found this newsletter valuable please subscribe on LinkedIn.