Structure and How To Get It¶

This here is an informal crash course in establishing structure in an unstructured professional environment. It won't get you to corporate competence, but it will deliver you from hustling and cowboy coding to structured, confident, business.

You do that by first establishing your cornerstones, then documenting the basics, then establishing an internal dialogue and "culture" of structure. All of these things are building an immutable and trusted foundation upon which everything else can rest.

Cornerstones¶

The basics of structure as an employee or under-management understands it hangs like curtains from a basic business scaffolding. No stable structure can exist without the basics of successful business transactions being stable underneath it. These cornerstones must remain solid, or the rest is meaningless.

Your cornerstones are: roles, contracts, and monies. There are also two lesser cornerstones: training, and sales.

Cornerstone: Roles¶

You can't work if you have no workers. You can't do good work if you don't hire good workers. You can't decide what a good worker is until you can describe their role and its criteria for success and failure. These are facts, and can all be encapsulated in a well-documented accounting of your needed roles and positions.

Here's an outline of questions and concepts that you need to be 100% sure of the answer to for each role:

What specific actions and tasks is this role responsible for?
What criteria would indicate that a person is successful in this role?
What criteria, if any, would indicate that a person has failed in this role?
How does this role fit in the pay scale?
Does this role require management or supervisory skills? If so, what, and to what level?
Does this role require training skills? If so, what, and to what level?
Does this role require financial or business skills? If so, what, and to what level?
Does this role require legal skills? If so, what, and to what level?
Does this role require sales or communication skills? If so, what, and to what level?
Does this role require proprietary, trained, or industry skills that are harder to find?
Who does this role report to?
How many people will report to this role?
Does this role have progression? (Junior->Senior, Programmer ½/3)
What is the title for this role?
Will this role have a probationary period by default?
Is this role temporary?
How many employees with this role are necessary?

Upon answering these questions, you should have a well documented and precise package that describes a discrete role. It should be something that you can print out and give to someone on their first day to explain your expectations from them, and it should be something you could post verbatim online (with some marketing fluff) to hire someone new.

Minor Cornerstone: Training

While training can be taken care of in the "Documenting the Basics" section, it should be understood that as you grow, you will need to solidify a role-based training regimen sooner rather than later in order to be successful. There is just no way to reliably hire exactly who you need in the quantities you need them in. You will have to fill in gaps in knowledge and ability as you grow. Defining what will be taught to whom, who will be the trainer for each role, and what criteria tells you if that training was successful are all necessary to create a machine that runs itself.

The goal is to provide pre-made training for any and all topics covered by any and all roles. If your training is atomic like this, you can quickly generate training plans to shore up new employee weak spots, or even create yearly refresher courses for long-time employees on important tasks. These training nuggets should rely heavily on the underlying checklists and documentation, but should be helpful wrappers around those documents rather than just the checklists themselves.

Cornerstone: Contracts¶

While not every company conducts its business with contracts, we do. Contracts are legally binding, and describe what each party is responsible for. A vague contract leads to vague requirements, which leads to vague timelines, and vague pay. "Vague pay" is exactly as undesireable as it sounds.

Consult a lawyer or other legal entity and create a basic contract boilerplate. This document must use strong language, and it must include clauses for:

How the client should pay you,
What rates you charge, or how you calculate payments, or a range of payments observed historically,
When they should pay you, or over what period,
What happens if the client does not pay you,
What happens if you cannot execute on-time or on-budget or at all,
The fact that you will execute against an agreed-upon requirements list and no more,
The client's options for withdrawing early,
Your options for withdrawing early,
The client's options and necessary actions/meetings for modifying requirements

Nowhere in those clauses is schedule mentioned, nor are any project-specific concerns like who will do the work, or what meetings you'll have. This is essentially a shell for the actual contract, and should be the same for all clients. Resist the urge to go against these basic stipulations. As soon as you do, your cornerstone is no longer stable, and your structure is threatened.

With this legal document as your basis for contracts, now you can extend it to include either sections or addendums (separate documents) containing requirements, schedule, and other responsibilities that are specific to a project or projects. The schedule cannot exist without requirements, and requirements should not be gathered if they can't agree to our pay demands. This is how software contracts work: pay (and other legal concerns), discovery, requirements, schedule, execution, testing, implementation, maintenance. Resist the urge to do this out of order. As soon as you establish a schedule before the requirements, or as soon as you embark on a project where the pay is vague or uncertain, your cornerstone is no longer stable, and your structure is threatened.

Minor Cornerstone: Sales

In order to sustain growth, you will eventually need to have a dedicated sales arm in order to fund those people and technologies. A salesperson needs to be defined like any other role, and subject to process just like everyone else (See "Documenting the Basics"), but their job can often conflict with how software is planned and implemented. Some of their greatest tools are price and time, but neither can be sold for a pseudo-creative type of work like programming before the project's extents are known. That's a problem.

To help get around this, consider making the involvement of a project manager a fact from the beginning. If both roles are following and advocating your process, the disconnect between traditional sales and software development should be lessened. Additionally, being approached by a team reinforces that you know what you're doing, and that you have a stable way of doing it. That team cuts the dread of working just with a sleazy salesman, but also helps grease the wheels a bit against the stingy project manager.

In any case, the important thing is to make sure your salespeople stick to the narrative and respect the process, even if it means their sales pitch is a little less juicy. If a salesperson can destroy your way of life in a single sentence, your cornerstone is no longer stable, and your structure is threatened.

Cornerstone: Monies¶

Proper money management and invoicing underlies all things in business. While it is certainly possible to derive hundreds of metrics and values using your financials, you need to be able to answer basic questions about your finances.

How much is rent?
How much are utilities (including internet)?
How much are tools and services (photoshop, hosting, slack, zoom, etc)?
How much is payroll per period?
How much (estimated) will taxes be?
How much is waiting in A/R?
Am I red or black right now?
Am I red or black at the end of this quarter?
What are my good months and bad months?
What are my big clients and small clients?
What are my efficient and inefficient projects?

There is so much more to it, and I am not the person to be dictating business administration; however, these metrics are simple, and can be used as touchstones to make decisions as an executive. Being able to accurately project your monies forward into time allows you to take risks or act conservatively, and to influence the direction of the company and its employees. For example, during your historically bad months, could sales efforts be increased? Could employees be given vacations to improve morale?

It can be hard to look at your numbers, and it can be daunting to gather them, but at the end of the day, the money is the lifeblood. It is more important than checking what movies are coming out, how your favorite sports team is doing, or what's new on reddit. It is more important than being lazy and not wanting to do the work to maintain everything in SAP. Whether the numbers are good or bad, knowing them should give you the confidence you need to make the decisions you need to make.

As this is largely handled by someone who knows what they're doing already, I only include this because it is a cornerstone of successful business, and deserves mentioning as such.

Documenting the Basics¶

With your cornerstones solid, start documenting everything, but start at the lowest level. Answer the question "when I do this, how do I do it?" Start with the very basics, even if everyone knows how to do it. Especially if everyone knows how to do it. These can be checklists, diagrams, pictures, or just official documents describing things. Your documentation must be stored all in the same place where it is centrally accessible.

Setting up or turning off accounts (domain, email, slack, freedcamp, bitbucket, etc)
How to conduct interviews, what questions to ask
How to cut checks and/or run payroll
How to deploy to production
How to request office supplies
Role specific duties (how to use git, how to write requirements, how to behave while on-site, etc)
Culture- and industry-specific narratives, phrases, words, and behaviors used in the company or by clients
How to conduct meetings (standup, discovery, phone interviews, etc)
Password and sensitive information security
Style and design guides
Code and directory cleanliness guides
How to request a conference booth or presentation timeslot

You start with the very basic, most atomic parts of your work because "structure" is just a series of smaller structures built on top of eachother. The foundation must be solid before you can build on top of it. If you have no grasp of the basics of your business and its roles, how can you orchestrate those tasks at a higher level? How can you solidify those behaviors and rules into the fabled process?

You document things everyone already knows because at some point, those things will be challenged, or will no longer be totally known. You will hire someone who does it completely differently, or who has never even heard of this thing "everyone" knows. Having something official, something written down, to fall back on is paramount to a smooth and hitch-free process. Trust me, document the small stuff. Yes, even if it's painfully simple and never gets looked at, it is still worth the time.

Once you have the very basics handled, you can now use that body of knowledge to move on to higher-order documentation and orchestration. This usually involves the when of these tasks, as well as grouping tasks together into multi-role and/or multi-phase megatasks. This creates a hierarchy of clearly defined tasks that anyone can follow, and will persist even if your company experiences failure and knowledge-loss.

New employee onboarding
Running the books every pay period
Conducting new client exploration
Conducting new project discovery
Employee feedback and reviews
How to deal with data breaches
How to determine who's in charge
Making changes to the documentation itself
Managing company social media
Yearly maintenance tasks (hardware refresh, ordering new keys, employee anniversaries, etc)

This intermediate level of documentation encapsulates the core movements and activities your business must do, and will make it very obvious if you've skipped over the documentation of a basic task. With this body of knowledge, someone should be able to resurrect the company after we've all died of the zombie virus - well, the everyday duties and tasks, anyway.

Establishing the Internal Dialogue¶

Finally, we arrive at a crucial moment. We have the basics of business buttoned up; we have every little task written down and checklisted so thoroughly that a monkey could do our jobs. Now it's time to execute... right? But execute what? All we've done is write down what we already do!

Now is when you establish an internal dialogue and culture surrounding this structure. None of this effort means anything if it sits on a harddrive or binder somewhere, never to be seen again.

At this point, repeat after me: this is how we do it. This is how we do it. It's in the documentation. It's all a part of the process. Did you read the checklist? Oh, there's a procedure for that. What document has this task? What sections does the new guy need to brush up on? Could you write up a process document for that new task? What does the documentation say about this? According to our process, this is how it's done. Make sure you amend the process document after the meeting. Oh, that's easy, just follow the procedure in the documentation. This is how we do it.

When you cultivate a workplace mentality that includes and references the process, it becomes a capital-P Process. It becomes standard. It becomes the way. That's how all these big name processes are born - someone wrote down every little thing of how/who/when, and lived it long enough that others took notice. Process doesn't happen overnight, but is the result of codifying and boiling down what you do into a package that everyone can own and refer to.

While initially this adoption and mindset will come from management and structure-minded people, you will find that if the documentation is accessible, efficient, simple, and well-written, workers will ease themselves into it on their own. It's a safety net. It's some guidance they can fall back on rather than to appear uncertain in front of others. It's built by us, for us.

More than that, this process-mindedness must extend outside the company. If we have a specific way of doing things, our clients need to know that if it will affect them. Having and sticking to a process makes you seem more knowledgeable, responsible, stable, and professional. In general, people respect the process, especially if they have their own to follow.

Next Steps¶

Once you have your capital-P Process up and running, with a supportive culture surrounding it, now you officially have structure. Continue documenting basic tasks and duties as you acquire new roles, projects, and capabilities. Continue fostering a workplace that falls back to its checklists where it can. Continue advocating for your way of doing things, even to outside entities and clients.

At this point, you can look into other processes to see if they agree with how you do things. As an example, Scrum or some other Agile process will provide a more specific and industry-proven scheduling and role-based way to understand your projects. If it's compatible with how you already do work, but would fine-tune your project management... try it out. Do your research, apply it on top of your existing process, and see where it fits or doesn't fit. Making these decisions is much easier when the underlying process is well-known and atomic.

Consider having meetings with the different roles in your company to determine if the body of documentation and knowledge that represents and guides them is accurate, and what could be improved. Open this door at most once a quarter, if not once per year or less; structure is not attained by changing everything all the time. The process must be allowed to adjust to changes, and for the new procedures and ideas to sink in and become routine.

If your process is particularly successful, give it a name and present it to the world. Even just writing a Medium, Quora, or Reddit article about it can gain you exposure and traction in ways beyond what you normally do in your field. For example, you may gain legitemacy as a process consultant if enough clients are impressed with your process. Your company may also be featured in a magazine or popular website, increasing your reach.

Summary¶

Nail down the basics of business first. Understand your company's roles and positions. Define and solidify your contracts and legal connections to your clients. Stay on top of your expenses and accounts.
Document everything, even the painfully easy, or most widely known task, and even the difficult and hard to describe task. Everything. At the smallest, most atomic level possible.
Create a process out of those smaller tasks by stringing them together into logical groups that encompass a broader facet of work, or represent a period of time where multiple actors will need to do their jobs.
Foster an environment that relies on this process and refers to it whenever possible. Leave nothing to creativity or chance if you can. Refine these checklists and documents until they're efficient and fit together in a package everyone can own.