Tactical suggestions for developing non-coding skills

Facilitate a meeting

Resign your self to be the meeting facilitator, not a stakeholder. You faciliate it so the group can answer the question which instigated having the meeting in the first place.

Identify what question you need answered. Define the meeting objective. If you want to cover specific points, create an agenda. This helps everyone focus.

Share your screen, show what you’re talking about; whether it is the agenda, objective, question to answer, Jira board, code, or a slide deck. Alignment is easier if everyone looks at the same thing. People interpret words and phrases differently. Have a visual to help get everyone on the same page, literally.

Ask calibrating questions. People love to be asked “what” and “how” to do something. “Why” triggers defensiveness. Calibrating questions are a great way to encourage the less outspoken people to offer opinions. It is less accursatory than calling people out directly.

Communicate a design

I have never been one to create a design doc. But I do leverage drawings to communicate. Leverage the C4 Model for Visualizing Software Architecture.

Share your screen while creating a design, ask calibrating questions and incorporate feedback real time, get everyone on the same page, create shared ownership and apply 2nd order thinking.

Mentor others

The terms Mentoring and Coaching are often used interchageably but are not the same. When mentoring, you are usually sharing your experience, listening to someone (refer to Rubber Ducking), and sometimes offering advice. When coaching, on the other hand, you are offering tactical suggestions on how to accomplish a goal.

Mentoring skills are complicated. But I think the first step is to learn how to identify peoples strengths and weaknesses. Label or classify them so you can effectively articulate them. This is really so much harder than it sounds so spend some time and really figure this out. Analyze yourself for practice. You will learn how to provide feedback, ia key skill to level up, yourself and others.

I leverage the Dryfus Model for Skill Acquisition as a way to identify where people are in their journey with a particular skill. And then I use the disc profile to determine how to communicate feedback to them.

Educate others

Managers need to have some level of understanding about technical details in order to protect the team, explain issues to stake holders, etc. But if you get frustrated and impatient with them when they are talking about technical concepts, you will quickly lose their respect. And possibly become known as a jerk.

Recognize everyones expertise. So be gracious, share your knowledge, consider the impact you make when you arm people with knowledge for them to do their job well. View the moment as an opportunity to help others. Approach it with an open mind; you might learn from the experience.

Influence others

This is really about selling. Selling your ideas, your code design, your library.

You have to communicate with others before you can influence. So build relationships. Make friends. Listen to others.

Listening was really hard for me because I wanted others to listen to my ideas. But at some point I realized everyone wants to be heard. As soon as I started to listen, others started to listen.

Leverage a technique called Mirroring to start listening. Use it to get the other side engaged, feel like they are involved, and to tease out information you might not have otherwise.

Mirroring is repeating 1 to 3 words, typically the last ones, of what the other person is saying.

In addition to listening, ask for help. Asking for help makes others feel appreciated. And feeling appreciated makes people realize you are on their side.

If your trying to influence others, you have to be open to being wrong and let others be right. And if you have a gracious, bountiful mindset, you’ll create win-win situations where everyone feels good about the outcomes.

Practice system level thinking and understand the Theory of Constraints. Sometimes, implementing your solution does not help the whole system. People default to locally optimize for themselves, only to create bottlenecks elsewhere.

Make the work visible

As an early career engineer, I hated giving status updates. But I finally realized I was doing myself a disservice because others did not know what great work I was doing. I started to advertise for myself and for my team. Sending my manager weekly highlights for the team. Collaborating closely with Project Managers, making sure to explain technical difficulties and ticket statuses so they too could advertise for us as well. If you don’t advertise, nobody will know.

Leverage technical debt

Technical debt is bad right? Not always. Sometimes we take on technical debt in order to deliver value to the customer faster. So, just like credit card debt, we take it on so we can “buy” something now. The trick is to clearly communicate the debt (make the work visible) and record it in the teams project management tooling (i.e. create a Jira ticket for prioritization in a future backlog refinement session).

Making the technical debt visible provides recorded ammunition for when you have to convince managers to take on non-trivial technical work to enable unblocking flow (unlocking value) in a particular area.

Advertise

Start creating decks in Powerpoint or whatever slide deck tool you have. Leverage decks to communicate ideas, sell projects, get alignment. Their easy to email and share in a video call. I use The Noun Project for icons.

Build relationships

Set up 1 on 1s. Have them with your peers, your manager, your managers managers, the CTO. A good rule of thumb is ad-hoc with your peers, bi-weekly with your manager, bi-monthly with your managers manager, every 6 months with your managers managers manager, etc.

How to setup a 1 on 1 with the CTO

Admitedly, this is difficult. A possible opportunity is when you first start a job; email them introducing yourself and ask if you can get on their schedule every 6 months. You could also ask your manager to see if they have any suggestions.

Talking with people is a great way to build relationships, find mentors, learn, grow and be happy in general and it takes energy. So find out how you recharge and make sure to make the time to recharge. You are going to need it.

My last point is to learn how to be optimistic, not pessimistic. Now I do not mean you have to be positive all the time, balance is key. Optimism does not equate to “be positive”. Optimisim is being hopeful for the future, as opposed to believing the worst will happen.

We can communicate risks while being hopeful we can mitigate them. So learn to be optimistic. It is infectious and if we believe the Law of Attraction, it will lead to a happier you and a happier others.

Inspired by An incomplete list of skills senior engineers need beyond coding.