• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Structured soft skills (not only) for Technical Leaders - Agilia Brno 2014
 

Structured soft skills (not only) for Technical Leaders - Agilia Brno 2014

on

  • 152 views

You are not a born leader. You haven't been prepared to be one but you were chosen to be. And then everything changed. Now you should be a good communicator, negotiator, mediator, facilitator, ...

You are not a born leader. You haven't been prepared to be one but you were chosen to be. And then everything changed. Now you should be a good communicator, negotiator, mediator, facilitator, motivator. You have heard that you should be a servant leader, should prefer collaboration over contract negotiation, people over processes but … you think: „What the heck should I exactly do?“ Most of the leadership hints are general, fuzzy and unstructured. If it sounds familiar to you, this is a talk for you.

We will talk about fundamental soft skills in a structured way. You will see a lot of schemas, diagrams, algorithms, dependencies you weren't aware of before. This way misty soft world will become familiar and easier to understand for left-brainers (people loving to think in an analytical way).

What we will talk about?

How to resolve tough (conflict) situations.
How to find a problem solution.
How to conduct effective meetings in a way nobody told you about earlier.
Who will benefit from this?

Technical leaders, team leaders, any other kind of leaders working dealing with software development.
Leaders and all technical folks interested in developing their soft skills.
Technical guys (developers, testers, ux designers) at least having clue that soft skills might be really important in their work.

Statistics

Views

Total Views
152
Views on SlideShare
144
Embed Views
8

Actions

Likes
0
Downloads
2
Comments
0

1 Embed 8

https://twitter.com 8

Accessibility

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Structured soft skills (not only) for Technical Leaders - Agilia Brno 2014 Structured soft skills (not only) for Technical Leaders - Agilia Brno 2014 Presentation Transcript

    • Mariusz Sieraczkiewicz @ms_bnsit_pl http://msieraczkiewicz.blogspot.com http://bnsit.pl Structured Soft Skills (not only) for Technical Leaders
    • Typical career path in IT Junior developer Developer Senior developer Tech/team leader
    • Stereotypes about tech guys Non communicative Binary way of thinking or at least strictly logical Structures, models, algorithms Afraid of people – non-assertive or aggressive
    • Challenging mismatch A tech guy organizing work of a team Not ready for the role Non-technical guides about soft skills
    • Soft skills Personallity traits optimism, common sense, responsibility, sense of humour, integrity And abilities empathy, teamwork, leadership, communication, negitiation, sociability, ability to teach … a lot of emotional stuff
    • Experiment
    • Structure of emotions
    • Structures, models and algorithms Easier to understand (especially for tech guys) It is always a simplification It is like a pattern you have to adopt You need a lot of practice and flexibility
    • Using soft skills structures is like using stair railing. It might dangerous to go without it.
    • Conflict resolving Hello World
    • Somewhere in one company… PMs and Devs
    • Many small conflicts less documentation vs. more documentation more time for refactoring vs. more time for features PMs having more understanding of technical aspects vs. we don’t have time for that
    • If you try to convince each other You will mostly argue Usually only one side wins (if any) At best you may compromise
    • You can’t resolve conflicts on a level they arose
    • Conflict resolving Hello World
    • I want a blue color I don’t want to live in hospital (NOT WHITE) Grrrr… I want white! I want a very bright color Pink Why is it important? Why is it important? Him Her No, I don’t like pink as much as white Maybe another bright color Bright violet
    • Statement (I want a blue color) Need (NOT WHITE) Statement (I want a white color) Need BRIGHT COLOR Possible Solution (PINK) Why is it important? Why is it important? Her Him Need (NOT WHITE, NOT PINK) Need BRIGHT COLOR Possible Solution (BRIGHT VIOLET)
    • Conflict resolving basic structure
    • Statement Need Statement Need Possible Solution Why is it important? Why is it important?
    • Main questions you may ask to level up the discussion Why is it important? What do you need in this situation? What would you like to achieve this way? If we do it this way what will change?
    • Conflict resolution algoritgm 1. Assure all participants want to find solution satisfying both sides 2. Get an agreement for this using this structure 3. Begin from the statements 4. For each statement look for a need asking why- like questions 5. Having both needs look for an alternative – new solution 6. If a new solution is not satysfying for at least one side ask why 1. Redefine the need and go back to 5 2. Formulate new statement and back to 3.
    • Another samples
    • You don’t have a technical knowledge Easier to talk about requirements and their consequences Be able to talk about choosing better technical solutions We are not paid for this Time for supporting project success Project success Devs do minimal technical knowledge training for PMs Why is it important? Why is it important? Why is it important? Why is it important? Dev PM
    • Requirements are fuzzy We don’t want to change code all the time and still conform the estimation Safety and respect for my work You should figure out the details We want development to move on before knowing everything When moving on we have a better chance to meet a deadline Let’s work in increments Why is it important? What do you need? Why is it important? What’s your need? Dev PM Safety - I can reestimate after changes Respect for my work - Requirements changes don’t blow my code out.
    • I don’t want to be invited unnecesarily to meetings I want to spend time effectively Your knowledge might be cruciual We can make better decisions • Partially participating in meeting • Be ready for consulting • Let’s analyze last cases Why is it important? Why is it important? Dev PM
    • Problem solving
    • How do we usually try to motivate?
    • People don’t like to be told how to do their job They feel incopetent They feel like pupils at school It diminishes his/her position … but there are situations when you should tell sb what to do …
    • Ask questions This breaks a pattern of casual thinking There are some questions specially powerful You are likely to know one of this question if you are using …5WHYS
    • But questions are not enough
    • A – specifying current situation Qustions for exploring A What do you concretely mean? Check if problem is specific (How not to surrender to the customers’ pressure? - What kind of pressure do you mean? Which customers? All of them?) Check if problem is not too big (How to make team work efficiently? – What kind of team work aspect do you want strenghten? Split it to smaller chunks.) Is it really a problem? (How many times it happened?)
    • A – specifying current situation Questions for consequences and intent What is possible in this situation? What is not possible in this situation? Why does it happen? What’s good in it?
    • B – specifying target situation Questions for exploring B How would you like it to be? How should it work? What it would be like? Check if it is specific and not too big Questions for consequences and intent What would be possible in this situation? What would not be possible in this situation?
    • Delta – how to get there
    • How to simplify it?
    • How to simplify it?
    • Structuring meetings
    • How does it usually look like?
    • Core anitpatterns People not prepared The hidden bottom Drifting away People not listening to each other Lack of meaningful results Lack of action plan Lack of structure
    • Meeting agenda 1. Introduction 2. Issues: • Too much documentation • More time for refactoring • PMs to have more understanding of technical aspects 3. Action plan 4. Summary
    • Let’s use conflict resolution structure Statement Need Statement Need Possible Solution Why is it important? Why is it important?
    • Or let’s use problem solving structure
    • Introduce the structure Conflict resolution Problem solving Facing the change Creating a plan Retrospective
    • Set or remind the rules „Only one person is talking” (especially when there are strong emotions, when you talk you don’t listen) „One side talks and then another” „A facilitator decides who talks next”
    • Frame potential problems „It might be difficult to talk about problems and this is why we suppose a positive intention…” „This form of meeting might seem strange for you but …”
    • Frame potential problems „You might want to talk about issues that are not in the agenda but …” „We might come across an impass while looking for a solution but this is usually the moment right before the success …”
    • Summary Using soft skills structures is like using stair railing. It might dangerous to go without it. You can’t resolve conflicts on a level they arose. Instead of giving advices or forcing someone to do something, start asking questions. Meeting agenda is not enough. Use deeper structure to make it effective.
    • Mariusz Sieraczkiewicz @ms_bnsit_pl http://msieraczkiewicz.blogspot.com http://bnsit.pl ?