The Transformation

Back in 1998 I got my first computer, in 1999 I discovered Pascal, and shortly after PHP. All my life I learned through projects much better than through theory.

I assume you are the same. Most driven people are, I found out later in life.

So I coded my own social network and asked all my classmates to sign up. Even though the idea was good and Facebook didn’t exist yet - the application sucked.

I just didn’t have the experience, nor the inputs I needed.

Once I started at a company to work as a PHP developer, my mentor at the time taught me an important concept: Database joins.

Yes, I coded a full web application without knowing joins. If you are a developer you might think “WTF, how did this even work?” (Answer: I stored ids but then ran N+1 queries all the time).

The problem was this: I didn’t know what I should know.

If you are about to create your own software project as a PM, PO or Founder, you might face the same.

Just getting a developer and ask them to do things might not be enough. You need to get an overview and then put the right people together to code a project.

This blog is about giving you all the right tools to do exactly that.

Where we come from

mario looking at a phone

In the last years I have worked with great PMs/POs and Founders who were either assigned to technical projects or they had an idea they wanted to realize themselves.

Some became excellent at that job. And some failed, became bitter, blamed developers, gave up. But all of them started from a non-tech field. Usually it goes like this:

Meet John, our reader avatar:

He has a university degree or experience in a managerial field.
His background is potentially finance, business admin.
He is from a western country, let’s say Germany for now.
As he is German, he knows how to do things right and how to check on quality. He also knows how to work with trade-offs and compromise. Reality is never as good as the plan and that’s fine.
He has never coded software, but always wants to try it out. At least he knows Excel very well.
He speaks fast, but also knows how to listen well.

After reading everything on my site (and hopefully applying the knowledge), you will be able to be just good enough in several fields. I believe that good enough is important: once you get okay at any area, you can move on to the next.

That’s important for a leadership role. You cannot be too detailed or you’ll waste time you need on oversight.

If you are anything like me, you will instantly connect with this mindset.

I myself went through this transformation, but I come from a technical role. This blog should help you understand several areas much better, and be good enough in all of them.

Hiring

It took me many years to figure this out. I want you to skip my painful lessons and go straight to the place where you will:

be able to write job descriptions (JDs) that are not just accurate, but also entice a developer to apply.
talk to developers on eye level so they feel understood
vet developers and designers and assess them correctly
call out the bullshit of unqualified candidates who might otherwise rob you of precious time

Leadership

Some say leadership is a talent, but I’m sure great leaders are made, not born. Great leaders do several things right and in effect you will:

be able to retain talent longer and with more motivation
find out when there’s a problem before a developer even notices themself
facilitate interaction in the team and find out how to put people into the right seats
be seen as someone people just want to work with

Tech concepts

I am sure you know many of the above concepts already. Now, tech concepts are something that’s super important to at least tap into. Why?

Because people want to feel understood. And understanding people means to dive into their world, at least a bit. My mission here is to break down tech concepts and explain them in a way you will be able to understand them.

After this 80/20 course you’ll know:

the trade-offs between certain technologies
why some features can become super expensive and how to deal with technical debt
when not to use fancy new ideas and rely on proven tech stacks
the gist of new ideas and the knowledge to assess if they are here to stay
when to know if it makes sense to overengineer and when to do quick fixes

Ruby on Rails

There are some tech concepts specific to Ruby on Rails. You can apply them to other similar frameworks (like Laravel, Django, Java spring boot), and they will still hold true.

For our case, I will stick to Rails, because that’s what my company, Pairing is doing for many years. We learned many lessons, which we want to bring to someone who wants to:

Estimate a project based on complexity of models, controllers, jobs.
Have an idea about popular gems (packages in ruby)
Not feel stupid when joining a meeting of devs and/or just listening

Productivity and Management

While I have deep respect for managers who have been in the field longer than me, there are some things I noted: many people think they are optimized, but there’s still room.

Especially we can learn from developers: As devs are usually lazy and try to solve things with software, they have some ideas on how to get a task done fast.

Also, everyone who builds and operates sy`stems likes to make the better. At least that’s true for me. I’ll share my findings here, and will also rely on your input. Please send me feedback along the way, I’ll most likely work it in.

How to start?

If you are in this transformation of if you think you can learn one or two things here, do the following:

Subscribe to my email updates
Send me an email and tell me 2 sentences about yourself: [email protected]