In our world of engineering management, a big question arises: “What is the best reward for an Engineering Manager?” People have many different answers to this. For me, the best reward is seeing my team grow and do well on their own.

Think about a day at work when your team is full of energy and ideas. They solve problems quickly and work well together. And you? You’re helping them succeed and focusing on the big picture. Your job isn’t just about managing; it’s about leading in a new way.

So, how do we make this happen? How do we unite a group to form a strong team that does better than we ever hoped? The answer is in encouraging initiative.

In this blog post, I’ll discuss the 7 Levels of Initiative, an idea from Steven Covey’s research. It’s not just a way to check how well the manager is doing in the team; it’s about helping our teams be their best.

Effective communication is pivotal in engineering management. This blog aims to dissect the intricacies of written communication, offering insights and practical tools to enhance your interactions.

While I’m no Shakespeare, writing gives me a sense of clarity. It’s a medium where I can truly articulate my thoughts and share knowledge. But let’s face it, written communication has its challenges—no facial expressions, no tone, just words on a screen. Understanding this gap is crucial for effective communication. This blog post aims to dig into the complexities of written communication, offering you a detailed roadmap for improvement.

Whether you’re drafting an extensive project plan or shooting off a quick Slack message to your team, the principles outlined in this blog can elevate your written communication across all platforms.”

Why written communication is challenging?
In verbal communication, tone, pitch, and facial expressions play a significant role in delivering your message. These non-verbal cues can help clarify meaning, show emotion, and give nuance to what you’re saying. Written communication lacks these elements. Words on a screen don’t carry tone or facial expressions, making it easier for the message to be misinterpreted. For instance, what you write with a positive intent could come across as neutral or even negative to the reader.

Imagine a skilled craftsman meticulously building a wooden chair. The finished chair, sturdy and polished, is the output. But if nobody finds the chair comfortable, the intended outcome, a satisfying seating experience, is not achieved.

This simple example from carpentry resonates deeply with the complex world of software engineering. Have you ever heard of o Software Engineer who does not like to be named Craftsman? The nuance between outcome and output is not philosophical and has profound practical implications. As software engineers, focusing on both aspects can lead to projects that are not only technically sound but also aligned with user needs and business goals.

When I started my career as a software engineer, I didn’t have any map or list of skills that are necessary to succeed. I’ve spent too much time on unimportant stuff, a far too little on crucial things. If you know at least something about software development - you can create web service in Django, or build microservice in Spring, crate some machine learning model, or write Spark Job - and you want to advance your career to the next level, this blog post might be helpful for you.

Before we start, I have good and bad news.
The good news is that at some point you will have to unlearn what you have learned. If you learn something, you are becoming blind to other things that you can learn. Remember, you are a creative person; your mind should be free and open for new waters. Do not be afraid to forget stuff.

The bad news is that you will probably never stop learning.
Over time, some things became similar, and we use similar design patterns in different contexts. Even that something is similar, it is not an excuse to stop learning. You need thousands of hours of practice and writing software to be good at it. Besides spending many years writing software, I know that I have deficiencies in some areas that I want to improve.

In the past few weeks, I’ve read Getting Things Done, Technical Leadership, Elon Musk Biography and The Decision Maker.

Each of these books was good. But “The Decision Maker” is a game changer and I can’t stop thinking about this book. It was worth reading - for sure. I’ve decided to write a short book review and note the most important facts that I’ve learned from this book.

Review

This book is a story about a company and its new owners who have left the corporation and decided to build a great place to work. It is full of dialogues, issues, and situations.

By observing those scenes, the author presents ideas and values that matter when you have to lead the team or the company.

Is this book only for managers or bosses? Certainly not. If you work with other people or deal with non-trivial tasks, this book is for you. For me, it is an appropriate supplement for any “Agile” book.

Blueprint presented in this book is a good starting point for setting up company culture.

The story did not take place in reality. Each scene looks genuine, but as a whole, it seems artificial. Like a romance from 90’s, when you know they will live happily ever after.

People

To begin with, you have to change your thinking about other people.

People:

• are unique,
• are creative,
• are able to learn,
• have different strong points,
• have different needs,
• like a challenge,
• are capable of changing the environment,
• are capable of making contribution,
• can be trusted.

Among some people, you can see those values. Among others, you have them hidden, and you have to unlock them.

But there is always somebody who disagrees with it and this is important to remember it. Do you see any similarities with Theory X and Y employees?

Decision Maker

Secondly, you have to choose the Decision Maker. It is a person who makes a decision. How to find them? It is simple.

The Decision Maker is a person, who is closest to the action. Bosses or leaders are not often deeply familiar with the situation. Usually, team members are often closer to the problem.

The Decision Maker has to be capable of listening and understanding other people. Making a decision is a process, in which you have to talk and listen to the others.

The Decision Maker should be aware of what is going on. Awareness of facts and consequences is crucial. If the person does not have basic data for making decisions - like company current finance status - you are responsible for unlocking that data.

Wisdom and knowledge are desirable qualities of that person.

It is a leader’s job to choose the Decision Maker. The leader should also observe and monitor the Decision Maker to see if he makes good decisions. If not, something should be done by the leader.

Results of making decision

It turns out that your employees’ decisions are often as good as or even better than yours can ever be.

People who are allowed to make the decision feel the ownership, because of that they will do everything to make the best possible decision.

Advisory process

The purpose of the advisory process is to look for a wider perspective.
The Decision Maker should ask at least a few people what they think about the decision.
He or she should ask:

• team members,
• other people with experience,
• subordinates and superiors,
• anyone who can help.

But the Decision Maker should take the final call.

Silver bullet

The decision maker process is not a silver bullet. It is only one tool or technique. The bigger picture is not straightforwardly visible in the book.

Between the lines, you can see many behaviours and dialogues which look familiar in “Teal Organizations”. If your organization is not ready, the decision maker process is definitely not the road to follow.

Photo credits:
Banner
Thumbnail

Motivation to this post

Software developer skill set should not be limited to hard programming skills. Also, important for of our work is communication, problem understanding, self-sufficiency and other soft skills.

It this blog post, I would like to show the positive aspects for software developer who participated in agile like conference. You will also find here a lot of information about Stretch Con, on which my experience is based on.

As a conclusion, I’ll present what outcome Stretch conference had on me.

Why I wanted to go?

There are many Agile/Lean/Leadership conferences, Thus, you do not have to choose Stretch. Look around for upcoming events, meetups or trainings. There is always something going on. But in this post I’ll only focus on Stretch.

On my regular basis I am software developer and at least half time of my job I spend on programming. My contribution in a company is not strictly related to any management role.

I wanted to go to Stretch Con, because I’ve belived that:

• Everyone is a leader of himself/herself. You have to manage your time efficiently.
• I can learn technical things by myself (by studying them). I did not know how to develop my soft skills – or at least I did not know how to start.
• Understanding processes, dependencies and co-workers’ and clients’ motivations are crucial and they improve the quality of produced software.
• You can not connect dots looking forward.

Stretch Con 15

Stretch was different, unlike any other conference I have attended, mainly because of the topic but also because of the fact that it forced me to think and interact.

Open spaces

Open spaces were great. Topics were shaped dynamically (voted via sli.do). It was a place where you could directly see, that other people, from different companies (different countries) have the same problems!

Regular form of open space

Those open spaces had a form of brainstorming ideas, where everyone throws an possible solution to the problem. It gave us the possibility to share and discuss ideas.

Joseph discussion panel

During the open space time, something unexpected happened. Discussion panel with Joseph Pelrine emerged. It started naturally, and eventually a lot of people accumulated around him. Gathered people asked Joseph questions, a he responded with deep explanation. Discussion was about:

• transparency,
• environment,
• estimation,
• product owner,
• estimation,
• ErlangC model.

And many more topics, but I was not able note everything. For such moments, it was worth going there.

Conference talks

In my opinion, on average every second talk was worth watching. I think it is a good score for single track conference. Listening to ‘leaders’, was priceless. Wide variety of subjects, helped me realize that this topic is huge.

Best talks

As usual, I would like to recommend 3 presentations which are worth seeing, but there are many more that migh interest you. Visit Ustream channel to watch them.

James Clear: The Surprising Power of Small Habits

After a great introduction, James presented detailed knowledge about the habits. He showed us techniques for shaping habits. Explained habit triggers. Finally, he also presented tricks how to sustain our habits.
You can read more about habits at James Clear Page.

Conference video available here.

Tim Steigert: Don’t blame the goats. Get a Goatherd

It was a presentation, that forced reflection about me. It helped me tu understand who is a leader, what is the team or company and how all of it this fits into our world. Most importantly, how to ‘get’ a goatherd.

Conference video available here.

Joseph Pelrine: Coaching “self-organizing” teams

Joseph started his lecture with explanation of Complex systems. Then, he started discussing social self organization. Among many concepts that he presented, one particularly stuck in my mind. You have to setup for good thing to hapen naturally. Then you have to monitor them, and decide what to do more and what to stop. If you want to know how to setup things, you have to watch video.

Conference video available here.

Conference itself

I’ll remember this event as something positive. Here is my summary.

Pros:

• Scene decoration was consistent with name of the conference. You may think it is not important, but it really helped me a lot, to put my brain into good mood.
• Content of the gift bag, including book “This is Lean“. For the first time I’ve received the book, instead of a useless gadget in gift bag. Great idea!
• Great venue localization. Venue itself was impressive, too.
• Selected conference speakers including book authors, people who change things (e.g. John Bunch - Holacracy guru at Zappos). I’ve had a feeling that Conference program committee, made many hard decisions.

Cons:

• Everyone were talking in Hungarian. It was so hard to start a discussion during breaks.

Outcome

I’ve made 464 lines of notes, from the whole conference. There were also official notes, in case I missed something. Great concept and great drawing.

I was there with Wojtek. After the conference we have spend 3 hours talking and discussing Stretch content. We’ve managed only to discuss only about few talks - there were a lot of material presented there.

On my way home, I’ve written down few action points, reflections about myself, that I will try to develop in the upcoming weeks.

• Consciously shape your habits.
• Turn the camera to yourself, see your actions and behaviors.
• Stretch your horizon, to look for new opportunities and possibilities. It will help you with problem solving.
• Do I really watch carefully?
• Try not only to hear, but carefully listen to your peers.
• Find better ways to communicate.
• Discover Holocracy and decentralized way of running organizations.
• Engagement, purpose, trust are more important than you think.
• People mindset exists.
• Research more about Complex systems.

In conclusion, I highly recommend attending this kind of event from time to time to every software developer. Surely, you will come out as a different person.

Making a big impact with software products and projects - Gojko Adzic

Before I read this book, I was on Impact Mapping workshop by Krzysztof Jelski on Agile By Example. I knew the concept. I practiced it in my company in one internal project. I am going to use it in next project with client. 

But now. About the book. The book is very good. The knowledge in this book is very concise. Which was good for me, but may be problematic for person who does not know the topic, because important parts may be missed. Because the book has a lot of condensed knowledge, I’m going to read it again.

I found things not directly related to impact mapping. For example chapter about iterative and incremental software building process. I liked chapters, which were abstracts of other peoples thoughts, for example Tom Gilb about metrics. It is an advantage.

I like the idea that the concept of impact maps has been described without going into unnecessary detail. This book is some kind of guideline, blueprint. And this is good. 

And the most important chapter for me was “Typical mapping mistakes”. It allowed me to find a place, where I do something bad (I was unaware of it). 

Apart from book. I asked myself, why we do impact maps? One of the main reasons is to create good channel of communication. To create a big picture view for technical and business people. Second reason is to decide, what should be built to achieve our goal, to reduce waste and over-engineered solutions. 

I strongly recommend this book and to try this technique. 

Photo credit