gregorojstersek

This is going to be a great hackathon!

I'm using Docker on a daily basis and sometimes it's frustrating to have the need to "restart it" for some reason. Maybe it's time to build my own one? :)

Everything that we build as engineers, we build for someone to use. There is always going to be an end user for us. The end users can be non-tech people or they can also be other engineers.

It’s really important to try to deeply understand them and put ourselves in their shoes. That’s how we can create great solutions for them.

A lot of people may be thinking of what exactly does a CTO do? Well, there is not one universal answer to that. What the CTO is doing heavily depends on the business and the size of the organization.

Also, every situation is different. Finding out what brings the most value to the business → that’s what the CTO should be focusing on.

The way we approach making changes and embracing them can really make or break the organization. Doing it the right way will ensure that the organization thrives, on the opposite side, doing it the wrong way can cause a lot more problems than benefits.

What are your thoughts?

What makes you a good developer, will not necessarily make you a good manager. There are different skill sets needed to excel in one or the other. As you grow more and more as a developer, you need to find challenges for yourself.

Especially when you are a senior for some time. Management is a different skillset that you need to develop and can be a great next step. In this article, I share my story from IC (individual contributor) to manager.

One of the first things that is important to define when joining a new organization is the tech strategy. If there is no tech strategy present already, it’s very important to start working on it. As you know, if you don’t have a plan, you plan to fail.

If there is a strategy present already, review it thoroughly and adjust it based on your findings. When doing this, it’s very important to keep in mind what makes the most sense for the business and your team.

Side projects are a really great way to grow. There is no better way to learn new technologies/concepts/frameworks than building an actual project.

Especially if you are passionate about the project and you are eager to learn a new technology or get better at it.

The main secret to being able to do this is freelance work. I wouldn’t be where I am if I wouldn’t be doing: projects, coaching and mentoring, consulting and advising.

This is how I am NOT measuring productivity:

I don’t measure lines of code being added. I don’t measure the amount of tasks finished. I don’t measure story points being done. I don’t measure the number of hours being online.

Instead, this is how I am measuring productivity:

Are they focusing on building the RIGHT things and challenging requirements. How much are they helping others. How are they contributing to the success of the whole team/organization. What improvements have they implemented and ensure they get adopted by other engineers.

What are your thoughts?

Your first 90 days are crucial and can define your overall experience in your next position.

It can be the difference between having an amazing experience and getting along well with your new colleagues or an experience, where you regret the decision that you made.

What are your thoughts?

1:1 meetings are an essential part of coaching and mentoring and if they are done in the right way, it can bring immense value.

What’s important to understand is that not all managers will be conducting this meeting the right way and that’s where it’s crucial that you take the initiative and drive this meeting in the right direction.

What are your thoughts?

Scaling your Software Development team can often be a daunting task. As soon as you grow to the mark of 5 engineers, that is an indicator that there needs to be a bit more structure in the team.

Imagine having 20 engineers and no clear structure and defined responsibilities. That is where uncertainty, misalignments, and miscommunication come in.

It’s important to separate the engineers into manageable teams, where correct responsibilities and ownership are defined.

So that the teams can function properly, there needs to be great leadership and that comes from the person that is appointed to be a team lead.

What are your thoughts?

If you don’t feel good, it’s going to be hard for you to help others and be productive professionally.

We make a lot of small technical decisions daily. Those decisions can be made quickly. For bigger decisions and approaches it’s important to take a bit more time. That’s where technical specifications become very important.

Technical specifications do not serve only for technical alignment between engineers, but they also help with alignment across organization.

Everyone interested in how a certain functionality is developed is available to take a look. This is a very powerful and transparent way to ensure cross-department alignment!

When growing to the architect position it’s important to understand next.

You have a much bigger impact with your technical leadership and enabling others, than just your own contribution.

Creating a good software development process is always a challenge.

There are a lot of variables that influence whether the process is going to work or not.

It’s important to understand that what may work for a certain organization may not for the other.

I’ve experienced a lot of different processes in my career and I’m sharing with you the process that works for my teams.

In this article I am sharing with you:

1. Process for Operational Teams - Process for handling tasks - Support to the process

2. Process for Product Teams - Process for handling tasks - Support to the process

What process works well in your case?

Building teams is always an interesting challenge.

You can’t just put Senior people from different backgrounds and mindsets together and expect that everything will work out.

You need to have people in the team that complement each other and have the right mindset.

It’s important to understand that one person can thrive in one type of team, but can ultimately be miserable in another team.

That’s why we need to build teams with purpose in mind.

We are going through the main types of teams: - Product Teams, - Growth Engineering Teams, - QA Teams, - Platform Teams

I've defined what type of people fit best for each respective team.

Being a good engineer no longer means that you only need to be technically solid, but you bring a lot of value to the company with your non-technical skills - soft skills.

This article is going to bring you some actionable insights and tips on how you can show your value as an engineer from the view point of a manager as well as a long-time engineer.

How does a great software development team structure look like?

When structuring teams it’s important to note that every organization is different.

You need to structure teams in a way that they will best fit to support the business.

The other way around does not work - business will not adapt to the structure of the teams.

You can expect to find: - An answer to whether you should split teams by ownership or function. - Different structure of the teams with my opinion on them. - What structure works/worked best for me.

What structure and seperation of teams works for you?

Behavioral interviews are a great addition to understanding the candidate deeply on their motivations and overall fit within the companies culture and mission.

The goal is to assess their previous experience and learnings. The focus is on learnings. We all have had previously bad experiences, the importance is on how fast did the candidate learn from them.

You can find 50+ questions and follow ups in the list.

Behavioral interviews are a great addition to understanding the candidate deeply on their motivations and overall fit within the company's culture and mission.

The goal is to assess their previous experience and learnings. The focus is on learnings.

We all have had previous bad experiences, the importance is on how fast did the candidate learn from them.

When growing as an engineer it becomes very important that you know and understand the options that are available to you. Knowing in which direction to grow is the best way to focus on the right set of skills needed to progress to the next step.

Everyone is different, and what may work for one person may not work for the other. It’s important that you play to your strengths.

If you are asking yourself which is the right engineering career path for you?

You can find my personal recommendation and insights in this guide.

Thanks for sharing John!

I particularly liked the Challenge: Building A Redis Server. It gives a really good high-level understanding of how Redis is operating. Good job!

I have a newsletter blog called Engineering Leadership (https://newsletter.eng-leadership.com/) and I write about (you guessed it :)) topics that are all things Engineering Leadership related.

The goal is to help:

- Engineers who want to progress their careers.

- Engineering leaders in the engineering leadership role for the first time.

- Seasoned engineering leaders who want to stay up-to-date.

- Founders who want to learn what it takes to build a high-performing engineering organization.

- Everyone who wants to learn more about engineering leadership topics in general.

Example of a post with very interesting discussions here on HN: https://news.ycombinator.com/item?id=36279323

Having a good hiring process is one of the most important aspects of a great organization.

It’s crucial to hire people that are a good fit and will ultimately contribute to achieving the goals of a company.

Working remotely provides its own set of challenges. When transitioning from on-site to remote, you find yourself in a situation, where you need to keep yourself accountable and not rely on others to do that.

Incidents are part of the Software’s lifecycle.

You won’t be able to fully avoid them, but when they happen there must be a good process in place.

The process should include: - reporting and resolving the incident, - writing detailed documentation and - conducting a retrospective.

The latter is particularly important so the whole team understands the issues that have occurred and collectively find solutions to avoid them in the future.

Your success is now determined more by the success of your team than by your individual contributions.

Everyone is different, and what may work for one person may not work for the other. It’s important that you play to your strengths.