Principles of Effective Work

Courtesy of Scopio / Noun Project

Spectral is a DevSecOps startup which I founded, that was born directly into COVID times (Spectral has since been acquired by Check Point 🎉).

When I founded the company it was not clear to anyone that COVID is there to stay (it was early COVID days), and obviously it is still with us for more than 2 years and counting.

What was very obvious is that to build a successful company in such huge uncertainty, and a good chance that we won’t actually meet through building the company, through hiring, or working together, introduces challenges around effectively forming a core culture that is as effective as I wanted it to be.

Even before COVID, we wanted to be a distributed-first company, but there was no pressure. But choosing to be a distributed company versus being forced to be (by COVID) one is different. As COVID evolved into the world epidemic that it is today, we had to improvise our way into being a full-on distributed company AND form a good and effective culture.

And so, on day 1, I set out to form some principles (that evolved) that we worked by to form a cultural backbone for a distributed company, winning over challenges and biases the are unique to working in distributed mode or just empower healthy work ethics.

Below, is the original page from our confluence (plus/minus some grammar fixes ;-). The format is a short: quick easy summary of the principle, followed by a few examples or suggestions to inspire what it means.

Hopefully, you can find it useful in your company to be more effective every day.### Principles at Spectral

• Leadership & Teamwork
• Trust by Default
• Explicit is Better than Implicit
• Go Start to Finish
• Just Enough Design (Engineering)
• Humans are Built for Duplex Communication
• Communicate Transparently and Actionably
• Communication Channels: More is Less
• Prefer Building Your Ideas Over Talking About Them
• Before Building, Explore Reusing
• Cultivate Long Time Stretches
• No Hand Waving
• Big Decisions Need Big Research
• Only One Person Holds the Ball at One Given Time
• We’re Meeting Averse
• Everyone is an Analyst
• Develop a Peripheral Vision### Preamble

Every company is created in a different way, and share some kind of explicit or implicit principles. If you are a bank, you have a certain set of principles, if you’re a Fortune 500 tech company you have another set, and if you’re a startup you have a different set.

If you have time, get a copy of Principles: Life and Work, if not, just get a summary.

In short: principles are a kind of in-betweens of code of behavior and are a determining factor for company culture.

Spectral has its own set of principles, and it’s detailed down below.

Our Principles

Leadership & Teamwork

This is how we see leadership. Best summarized by this 30min watch:

Please do invest the time in watching it. IMHO the lecture is more engaging than the book itself, but you can also read the book if you prefer.

Trust by Default

In some companies trust has to be “earned”, which means when you join, you need to earn your stars and stripes through hard work. We think that it’s wrong, unfair and not scalable. At Spectral, we trust by default — at the moment you join you’re given responsibilities as an equal, and we fully trust you.

We’re all trying to do our best assume the best intentions from people. see Poe’s law https://en.wikipedia.org/wiki/Poe's_law

When someone cancels a meeting on you, assume their house was burning and they had to deal with the fire, over a malicious intent.

When you feel misunderstood, or a lack of trust; speak from your heart. Talk about how it feels — it’s OK. When all else fails, you can also raise the issue with your team leader.

Explicit is Better than Implicit

Right off the bat: most companies have implicit principles. If you join you need to spend a year or two to “get” the company DNA.

By listing our principles explicitly, we associate ourselves with a different breed of companies, who prefer working in the open and sharing.

Explicit principles are better than implicit ones.

Setting expectations is better than hoping for them

Asking again is better than being shy

Don’t try to shorten your words in written conversation — initials/acronyms are rarely obvious in distributed context. Say the thing, unless it’s really obvious, which is rare to a general audience (which is the entire company). Prefer “Minimum Viable Product” over “MVP”.

Go Start to Finish

We believe a work half done is worse than a work that never started. When handing off a task, project, or anything really to a colleague, make sure it’s nicely wrapped, and not half baked. By handing over half-baked work, you’re forcing cognitive load, undo and redo of your work.

Decide to give it an extra push is better than leaving something open

If you can’t give it an extra push, turn it into a POC

If you can’t turn it into a POC, give it some nice documentation

If you can’t do that, write an email/message with ‘danger: half baked’ and arm your colleague with enough information to succeed.

Just Enough Design (Engineering)

Strive to have just enough design. In other words, when you’re designing things — leave wiggle room to revert your decisions without too much collateral damage.

You’ll always be learning in your first iteration and we want to get to the next iterations with knowledge we didn’t have in the first place. Big design upfront is a practice that takes into account the following: “There’s nothing to learn here, we know everything that’s there to know, let’s go for it.”. In some industries this is correct. But in most, it’s almost absurd to know everything there is to know, off the bat, right?

Design just enough for the feature, but then a little bit more.

No big design upfront

Design just enough, ask someone for feedback, and then give it an extra push

Humans are Built for Duplex Communication

If you want to do critical thinking and discussion — do it in a pair. If you have a group that needs to be involved, involve it after you have some kind of solid idea. We’re built for a dialogue — we have one set of ears and one mouth; and so — we’re most efficient transferring and receiving information in “duplex mode”, if you’re into engineering analogies.

If you have a deep design to do, make sure you have exactly two people in the meeting, not more.

It’s OK to say — we don’t know, need to investigate, we’ll split to pairs and come back

Communicate Transparently and Actionably

We think total, fanatic, and uber-transparency is bad, because many times chasing perfect transparency beats the purpose. But we do think that transparency is crucial, and that we open up everything we can, down to common sense. Here’s an example — after any session that feels productive you should ask yourself: “What can I sum up and send as a note to my coworkers, so that they get up to speed with my session?”

Not every meeting has to have meeting notes. Important ones should.

Every meeting should have something that’s actionable, document that, share .

Beware of meetings about meetings, followups on followups. This means you’re either (a) haven’t been preparing (b) havn’t been vigilant enough to extract actions from the meeting

Communication Channels: More is Less

Avoid communication channel fatigue — more is less. It’s easy to send your messages across: email, whatsapp, slack all at once in a blitz. It’s very hard for the receiving party to understand where to get what. Have only a few (one?) communication channels, and a clear map of what they’re good for.

Slack should be used for work, Whatsapp for off-work stuff. Don’t mix-and-match.

Avoid creating a channel for every topic. Channels should be team-themed.

It should be clear what every channel deals with, and where to get updated with what kind of information. It’s OK to kill unclear channels — in fact, developing an obsession to kill such channels is healthy.

Prefer Building Your Ideas Over Talking About Them

Building is cheap, talk is expensive. Wait what? isn’t the saying “Talk is cheap..”?. In our case, and especially in a distributed setting, talking in a synchronous way (AKA meetings) is forcing another party into participating right here, right now. You’re expensing your time as well as the other party’s.

Have an idea about a way to implement a data structure? Instead of talking about how to build it — make a branch, build a strawman implementation, and give someone a PR.

When building is actually expensive, fake it. Build a mock. Draw on a piece of paper.

If you have to discuss ideas (we all have to), better make it over some kind of asset: code, drawing, diagram, document.

Before Building, Explore Reusing

You don’t have to build everything. If there’s something that you can reuse, do that instead of building. This is a different version of “don’t reinvent the wheel” strongly geared towards startup productivity. But do it wisely, so that what you’re building doesn’t become a ball of mud.

The time when you build instead of buy will come. And you’ll know when it is time. The other way around — isn’t so clear.

Get a dashboard theme from themeforest, over building a complete UI dashboard from scratch. Start there.

Pay a professional to go over your blogpost for English grammar instead of spending days sending it to friends, family, colleagues just for the purpose of correcting English.

Cultivate Long Time Stretches

Be mindful of Paul Graham’s Maker’s schedule, Manager’s schedule. Whether you are a maker or manager, you can help at the very least — in not “vandalizing” other people’s schedules.

When you set a meeting, try to set it at the edges of the day. If you see a clear stretch of time for someone in the “maker schedule”, think twice before taking it.

Startup founders are both in the Maker and Manager schedule. Yeap. If you’re a founder, get used to the idea of impossibilities that you have to beat. If you’re working with founders, knowing this is useful.

No Hand Waving

We see hand waving as a bias that we fall into when we simply don’t have enough data. Hand waving always comes in disguise — like deep and informed knowledge, but most times it’s just a simple guess. Convince with data; not to say we all have to be analysts, so — convince with some data.

Ask bias-correcting questions for both organizational and factual fallacies — “ who told you?” “can you prove it with data?” “can you give a simple example?” “ who wrote it?” “is there something you can show?”

Investing half an hour with an experiment yielding data that supports your argument is shorter than the accumulating amount of time of “small argumentative wins” to classically convince people.

Some times data just doesn’t exist. Or it exists, but it sits beyond a wall that takes an unreasonable amount of time and resources to climb. In that case — make an educated guess, write down your thesis and risks, and go for it. Decide right there and then and take the risk. Make sure to check back later and see where or if you went wrong to learn from it. Some times not deciding is worse than being stuck in a cycle of thinking about taking the right decisions.

Big Decisions Need Big Research

But many small decisions deceptively appear as big decisions. So you need to first (a) make sure a big decision is really a big one (b) if it is so, invest the time in a proper decision making process.

Weigh and document pro/cons to get a realistic bearing that’s bias-free.

Document down your context. Your reality right now is different than the one that will exist in a year from now, when your decision will bear fruit.

Rubber-duck your ideas. Project your decision making process to your team (but present it with structure, no “free-form brainstorming”). Get feedback. Think. And get feedback again.

Only One Person Holds the Ball at One Given Time

But it’s OK to pass. If two people struggle to hold the ball together, it’ll drop. Hey it makes sense in basketball and also in tech. We all want to get the job done, and sometimes a communication breakdown may create a reality where two people are getting the job done in parallel.

Make sure each JIRA ticket has a reporter, and then and owner

Every task has a task owner. This is not necessarily the person doing the job, but the one responsible for pushing it forward. Many times this person would be both, but it’s not a must. Call it what you want: “feature owner”, “epic master”, etc.

If you’re handling something (probably something big enough), radiate it to your team. Sure; you have mechanisms such as weeklies, DSMs, but there’s no harm in over-sharing that you’re owning something that you think is important to share.

Ask for help.

Feel free to pass the ball if you think someone can do this better/faster than you, or if you think your time is better spent doing something else. But when you do, make sure there’s someone ready to receive your ball. Too many basketball analogies?

We’re Meeting Averse

A lot have been said about meetings in corporates; too much in fact. We take a position of — if you follow the principles listed here — then a meeting should look like this (this dynamic changes as the company grows substantially, but we’ll worry about this later — we’re still small enough):

It’s common between two people; it’s rare between more. In that case it’s common for it to even be a phone call.

Oh, and before all that, if you could pay a few bucks to buy instead of build what’s ever been discussed in the meeting — then you just save a whole lot of time not just in building but also in meeting.

Everyone is an Analyst

We’d like to promote a data driven approach, and factual thinking. By expecting everyone to give their analysis and take — we are practicing this muscle as a group. Data driven and factual analysis is better than guesswork and randomness, it allows us to be more precise, and hit targets on the first attempt; when we fail, we also know why. Other people call this “execution”.

When you share a news article, give a short gist + your take/analysis from it. Why is it important? how does it relate to us? what is immediately actionable from it?

When you look at a certain product flow, experience it yourself. Give your analysis. There’s a place for facts and emotion that the product provokes in you and we want to hear.

Use our competitors’ products, analyze our competitors and keep and updated and informed view of them (we actually do this during onboarding). It’s OK to like their product don’t hate it just because they’re competition — hate soon brings blanket dismissal, and dismissal soon brings blindness to their mistakes, and we do want to learn from their mistakes — it’s free learnings, without the battle scars and hits that they got.

Develop a Peripheral Vision

Your goal as an individual within our distributed team is to develop a peripheral vision. This happens almost always in small teams of 2–3 people sitting in the same physical place. People just know what’s going on in the product, business, people, and more. Ask questions. Be proactive.

Working in silos is bad. Simply because there will be a time where you’re expected to jump out of your silo and join a different one.

If you hand over part of your work, see that the person receiving got it properly. Or, the flip side of this: never hand over something that doesn’t work.

Ask questions. Be proactive. It’s worth stating it again. And if you find that you’re asking too much, there’s probably something that we can do company-wide to make sure this information is always visible and transparent. Let us know.

Good luck!