Brownfield

Many business owners are recognizing the value of utilizing a remote workforce. This can be a particularly effective employment structure for those who want to put together a team of remote developers. To ensure this type of setup will work for your business, make sure you have all of your operational functions in order prior to interviewing candidates, hiring staff, or launching operations.

Picture it, Silicon Valley (but remote), twenty nineteen.

I’m working at GitLab after being hired despite the job description saying “needs Kubernetes experience” and my interview featuring the concession:

Yeah, we don’t really see anybody with Public Sector and Kubernetes experience.

Picture it, still federal government contracting, twenty fourteen.

Mike has been managing projects for some years and decides to get certified just in case.

Picture it, federal contracting, twenty eleven.

Mike is a senior consultant at a consulting company that was bought by a military contractor who is trying to get into the cyber security space. Mike takes full advantage.

Picture it, suburbia, nineteen ninety eight.

Mike is a senior in High School and a new teacher has convinced the technical specialization wing to include an A+ Certification course. Mike takes full advantage.

In response to a twitter thread about questions to identify whether a applicant would want to accept a job, one of the most brilliant responses was by Lars Albertsson (@lalleal) asking “How much does it cost your company to buy a thing for 1000 EUR? Spend a day chasing approvals, and you are at > 100% overhead.”

The book Power to the Public by Tara Dawson McGuinness and Hana Schank is a fantasic overview of the Brownfield nature of the public sector. The book goes into a few fantastic examples of how things can be better.

Legacy organizations with legacy products have designed complex and rigid processes for releasing software into a production environment. The production environment is special and has limited access and compliance and constraints and needs to always work so developers shouldn’t even try to look at it.

Except things change and stuff breaks. So now what? Continuous deployment to the rescue!?

From experiencing organizations ranging from 10-person start-ups to dozens-of-thousands-of-people organizations, I have found a consistent experience among shared service providers. They say “no.” A lot.

As-of posting this, Mike is moving from GitLab to Coder. The purpose of this site and the gitlab.com group are not changing, though the day-to-day problems to solve are likely to be more about Developer Experience going forward.