author of the post:

I kind of enjoy working with partners, especially when everyone "knows their lanes" and agreements are properly defined. It just tends to blow up at some point it seems like... :)

The main goal is to keep a pulse on finances.

In any case, "start my own" is still on my todo, it's just... not that easy to pull of :))

My pleasure.

All sorts of questions - "What's the best way to do X?", "How would it impact security?", "Why we need this?", "What happens if this fails?", "Remind me how this works?", "Am I thinking in the right direction?"

Even more questions to the business / CEO ( Why this, why now )

"why", "how", "can we", "who can"?

Just try to be humble in the world where nobody knows anything (including yourself)... :)

Thanks!

I don't look at this like that, not any more at least.

It's been great five years for me and my family, exactly what I was looking for before the transition from stable corporate world.

I guess it depends a lot of personality and the type of work you enjoy. I thrive at early stages, where most things a built on common sense and you have enough power to shape things into something meaningful.

These days I try to appreciate "the process" (day-to-day) over "results" (exits).

You don't really have too much control of how things unfold in your life really, be blessed you are alive and kicking.

Do I say money is not important? Of course not - it's very important, but in a challenging times you have to test your limits and re-assess your priorities (whether you like it or not...)

It's easy to look at things in hindsight - the question is what is the alternative? 5 years of what?

We are still going, but it's a bumpy road. One of main products got delayed by partnering financial institution, which sent us into money crunch mode.

At the moment our engineering is ahead of our sales - which gave me some capacity to lift my head up and test my skills relevance against the market on the fractional/advisory capacity potentially turning into revenue stream with more control from my side.

You know how it works for us with engineering minds - you always consider worst case scenarios and try to mitigate them before they become real problems.

Based on my experience it typically works in cycles, where you need some sort of fresh blood every five or so years to re-kindle the spark and keep going.

It pretty much boils down to:

- Jira Epics (describe the why from the business standpoint)

- HQ meets two times a week to re-asses priority (drag up Epics up or down, or change priority) and monitor status

- Two week sprints where engineering leads along go through epics

- New sub-tickets created by engineering (including design) and assigned to specific people.

- Once thing are getting done, they are move to QA test status. After testing it either goes back to engineering or to Release Approved status.

- Engineer initiates and monitors the the release via CI/CD Jenkins pipeline.

That's pretty much it on the high level, unless I'm forgetting something.

One important note here - some time ago we made a decision to ignore "good ideas"/backog. We don't keep them in Jira until business is sure that we really need this particular functionality and ready to start building it right now.

That was somewhat radical and took some time to get used to, but it allowed everyone to focus on what's important now vs nice to haves to keep people busy with things noone really needs.

Overall there is no "generic" advice, everything is very org and stage specific. Common sense is the main guiding principle.

Pretty much what cialowicz said.

At the end of the day someone needs to answer a simple question - "Is the product functional right now / after the last release?".

If you don't have QA team you either rely on your product person to "give it a spin" or your engineering who are generally not very excited about clicking through the product multiple times (more often than not, they'll just leave it at the unit test phase and move on).

In small orgs that product person could be your CEO or CTO, meaning this will give them an easy false-escape into "micro-management" mode (aka feeling productive by doing low priority tasks) vs forcing them to make strategic decisions or worse, they'll just block the entire pipeline.

QA creates a natural quality gate looking at the product from the user's perspective, putting pressure at the engineering to deliver quality work and gathering leadership feedback at critical points only.