The intersection of technology and leadership

Category: Management (Page 4 of 8)

Book Review: Waltzing with Bears

I read this book very early in my career, and I thought it would be useful to read it again as a refresher to risk management. Waltzing with Bears is a book that focuses on the identification and management of risks within the software industry. It’s filled with a number of stories answering the question, “Why should we care about risk?” as well providing a number of strategies and tools for handling risk.

Waltzing with Bears

Although a lot of the advice is still applicable today, I think it is true that some of the recommendations are commonplace today. They recommend, for instance, an incremental delivery approach to software (Hello agile software development!) without a specific reference to a methodology as a way of mitigating risk.

They also present the idea of estimate (un)certainty and using the idea to make better commitments to others. They also warn against default behaviour that is still rife in our industry: e.g. making a commitment to others based on an optimistic estimate hoping for a series of breaks when it is clearly high risk, which later leads on to the project death march, or a huge loss of quality.

Reading the book the second time around, I picked up a few other interesting models I don’t remember so clearly from the first time around including the use of probability profiles (a graph that shows the shape of our estimates and the uncertainties) to understand when and where to give estimated dates. There’s a useful section around risk-storming for people who have never been to a risk brainstorming session, but that wasn’t particularly new for me. Another one is the use of the Monte Carlo simulation for calculating the impact of risks. After reading that section however, I feel like I still don’t fully understand it and I would need to practice applying it for me to fully understand how that works.

Although the examples used in the book are relatively old now, there are still powerful stories about how people failed to manage risk, what they could have done instead and what the consequences were (e.g. Dallas Airport Baggage system!) I also like their practical experience shared when they talk about the cultural side of risk (e.g. how transparent or open and organisation is) and when it’s dangerous to share your view of risk. This sort of advice is often missed from books where the authors provide a very one-sided dogmatic approach without the consideration of contexts.

Overall this is an easily digestible book that introduces the idea and the importance of managing risk together with tools to help you achieve it, all set in the software industry context.

Book Review: The Lean Enterprise

This weekend I finished reading a copy of The Lean Enterprise by Jez Humble, Joanne Molesky and Barry O’Reilly.

Top level summary: If you want to learn about the truly agile organisation, this is the book that shows you what it looks like.

The Lean Enterprise

I have read many books about agile, lean and organisations that build software, but this is the first that really brings it all together. Other books tend to be either too theoretical (founded from either Drucker or Taiichi Ohno) or with a very practical toolkit in a very narrow domain.

This book is aimed at executives and managers or organisations – the people with the authority to change to change the system. We know from W. Edwards Deming:

A bad system will beat a good person every time.

Like a book that was actually test driven by real-life questions, it provides answers to questions executives and managers ask time and time again.

The book is packed with information and provides solutions to problems that organisations, doing agile software development, struggle with in other parts of their organisation. Better yet they offer many examples of companies who are doing it right, proving that it is not just theory and that it can be done in many ways. There are many great stories from many industries demonstrating how different approaches can be yet still exhibit the lean attitude and culture that is so essential to success. I am also glad how much the authors focus on the importance of culture (and what people can do about it) and not just a single focus on either theory or tools.

The authors have done their research well, with excellent, tangible examples of lean concepts, practices and tools linked to much more detailed reading in a referenced article, paper or book. I would almost buy this book only to give people the reading list in the back – it is really that good. I have read many of the books referenced, and I remember how they challenged and changed my thinking in a positive way. After this book, my own personal reading list is also much richer.

What makes this book especially stand out for me is the pragmatic nature of the book. Even though, to many readers, the contents may appear idealistic or too unrealistic, the authors have given many examples of companies doing it, refer to many case studies or experiences where they have seen the practices and principles at work and shown their own insights into the challenges or dangers that lie ahead. This last part speaks volumes to the authors sharing their experiences about the questions some organisations have not even asked yet and advice on how to solve it. One good example is the paradoxical nature of balancing exploration through prototyping (discovery) against the disciplined nature of continuous delivery (e.g. additional work of well refactored code, tests and scripted deployments).

When I got to the end of the book, I knew that I would need to re-read the book for a deeper understanding because it is so rich with concepts and tools – some I have not had the chance to try out.

A perfect match for the target audience it was written for and a book that will continue to be relevant for many years to come.

Thoughts on OOP2015

I spent the first half of last week in Munich, where I was speaking at OOP Conference 2015. I missed last year when Martin Fowler was a keynote but had presented both in 2013 and 2012.

The conference still seems to attract more seasoned people like architects and decision makers and I am still constantly surprised at the number of suits I see for a technical conference – I do not know if that is more of a German culture difference as well. I felt like there were significantly more German-speaking sessions than English ones, and I sat in a number of them when I expanded my vocabulary.

I was only there for three of the five days of the conference, and was lucky enough to be invited and attend a special dinner on Monday evening where Dr Reinhold Ewald (a former German astronaut) gave a presentation about what it was like being an astronaut, what they do in space and some of the interesting challenges.

I saw a number of the keynotes and talks which I’ll briefly summarise here:

  • Challenges and Opportunities for the Internet of Things (IoT) by Dr Annabel Nickels – A relatively introductory session on what the Internet of Things actually means. The talk explained the IoT well, why it’s not possible and what people are experimenting with. It was clear that security and privacy aspects had not advanced and that there was still a lot of work to go, as there were lots of questions from the audience, but no clear answers in this space – more “it’s something we’re looking into”-sort of answers
  • Coding Culture by Sven Peters – Sven is an entertaining, engaging and obviously well-practiced presenter who knows how to engage with the audience with pictures and stories. His talk focused on coding culture – but more particularly the coding culture of Atlassian, the company Sven works for. An entertaining talk about how they work inside the company, but was not particularly surprising for me since I know already a lot about that company.
  • Aktives Warten für Architekten by Stefan Toth (Actively Waiting for Architecture) – A nice introduction to the Last Responsible Moment or what is more popular in the Agile community these days, Real Options.
  • Ökonomie und Architektur als effektives Duo by Gernot Starke, Michael Mahlberg (Economics and Architecture as an effective pair) – From my understanding, the talk focused on bringing the idea of calculating ROI on an architectural front. The pair spent a lot of ideas introducing financial terms and then a number of spreadsheets with a lot of numbers. Although well-intentioned, I wasn’t sure about the “calculations” they made since a lot of it was based on estimates of “man-days” needed and “man-days” spent/saved – it all looks very good when calculated out, but they didn’t really spent much time eliciting how they get estimates. They spent a lot of time introducing Aim42 which I wasn’t familiar but will now look into.

I ran two talks that had both good attendance and great feedback (like the one below):

OOP2015 - Best Talk

The fist was “The Geek’s Guide to Leading Teams” where I focused on exploring the responsibilities and remits of what a Tech Lead does and how it’s quite different from being a developer.

The second was “Architecting for Continuous Delivery” which focused on the principles and considerations for when people build systems with Continuous Delivery in mind.

I had a great time visiting the conference and had an interesting time expanding my German vocabulary as I tried to explain what I and what my company do in German – something I didn’t really do a lot of when I was living in Berlin.

Why you want to give up coding

A background story

A friend of mine worked as a Tech Lead, let’s call them Jo (not their real name) for most of their career. A few years ago, Jo moved into a management role that involved very little coding. They were no longer working full-time as a developer and they stopped playing a Tech Lead role. Jo now leads an organisation with six or seven large development groups.

In the definition of a Tech Lead, I suggested a Tech Lead should write code a minimum of 30% of their time. Jo managed to find some time writing code, but it was inconsistent – about an hour a week. In a 40-hour week, that is less than 3%. Jo missed writing code. Jo was no longer a developer and Jo was no Tech Lead.

What do you control? What do you influence?

Every role comes with a set of responsibilities, and the authority to fulfil those responsibilities. This authority gives you a certain amount of control.

For example, a developer has control over the code and tests that they design and write. Others may have influence over the code. Examples of influencing factors include architectural or product and/or platform constraints, team code standards and code reviews. Ultimately the developer has control over their own code.

Every company has a certain organisational design. Developers (and other employees) work within this structure. The organisational design impacts on how effective software delivery is. Rigidly hierarchical structures with completely different departments (e.g. developers and testers) have difficulty collaborating. An ineffective organisational design is a sore point for many developers because it makes delivering software much harder.

A developer has zero control over organisational design. They might be able to influence it, but it is ultimately controlled by managers. Some developers may try to change this, but most complain. I have heard this from developers in the past:

Who’s brilliant idea was to setup a development [team] like this?

Who's great idea was this?
Another example.

I can’t get anything done because I rely on those people to get something done and they sit on another floor.

Developers can complain, which is an ineffective style of influencing, although there are many more effective ways. In the book Influence: The Psychology of Persuasion, the author, Robert Cialdini outlines six key influencing strategies: Reciprocity, Commitment (and Consistency), Social Proof, Liking (a variant of the Halo Effect), Authority, and Scarcity.

Developers only influence their working environment. They do not control it. Note: An exception is, of course, when a company is small enough that the developer also takes on general organisational management responsibilities (e.g. in a startup)

Trading control for influence

Influence for control

Jo, who moved from being a developer to a Tech Lead, and again from a Tech Lead to a general manager shared an interesting insight with me.

You know those things I used to complain about as a developer? Well, now I have the ability to change them.

Programmers see the “non-technical” path as a path with nothing to offer. When programmers step into a leadership role, they inherit both responsibilities and the authority to control more of their work environment. A developer works within these constraints. A Tech Lead has more authority to change those constraints, and a manager even more authority to control and change those constraints.

How does this impact developers who become Tech Leads?

When developers give up their control in trade of influence, their sphere of influence grows. Instead of developing a single feature, they can guide the entire technical solution. The Tech Lead’s influence also grows between the technical and the business side. A Tech Lead has much more influence over how technology can be used to solve business problems, while developers are engaged too late.

I would suggest to Tech Leads never to give up all coding. Instead, it is trading more of the time you would spend crafting code, in exchange for a wider sphere of influence. The wider sphere of influence helps not just you, but also your team write better code in a better work environment.

If you liked this article, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub. The featured image from this post is taken from Flickr under the Creative Commons licence

The Definition of a Tech Lead

There are many names for leadership roles in software development such as Senior Developer, Architect, Technical Lead, Team Lead, and Engineering Manager. These are just a few. To me, the Technical Leader (Tech Lead) plays an unique and essential role that others cannot.

The Definition

The Short: A Tech Lead is a software engineer, responsible for leading a development team, and responsible for the quality of its technical deliverables.

Tech Lead

The Long: Leading a development team is no easy task. An effective Tech Lead establishes a technical vision with the development team and works with developers to turn it into reality. Along the way, a Tech Lead takes on traits that other roles may have, such as a Team Lead, Architect or Software Engineering Manager but they remain hands-on with code.

To make the most effective choices and to maintain trust and empathy with developers, a Tech Lead must code. In “The Geek’s Guide to Leading Teams” presentation, I talked about an ideal minimum time of about 30%.

Effective Tech Leads Code
An extract from the The Geek’s Guide to Leading Teams presentation

Not just a Team Lead

Early in my career, I worked on a team that had both a Tech Lead and a Team Lead. The Team Lead didn’t have much of a technical background and had a strong focus on the people side and tracking of tasks. They would have 1-to-1s with people on the team, and co-ordinate with outside stakeholders to schedule meetings that didn’t interrupt development time where possible.

The Team and Tech Lead

While the Team Lead focused on general team issues, the Tech Lead focused on technical matters that affected more than just one developer. They stepped in on heated technical debates, and worked with outside stakeholders to define technical options and agree on solutions for future streams of work. They wrote code with the other developers and sometimes called for development “huddles” to agree on a direction.

More hands-on than an Engineering Manager

You manage things, you lead people – Grace Hopper

Any reasonably-sized IT organisation has an Engineering Manager. They are responsible for more than one development, and have tasks that include:

  • Maintaining a productive working environment for development teams.
  • Acquiring appropriate budget for development to support business goals.
  • Representing the technology perspective on a management or board level.
  • Establishes and/or co-ordinates programmes of work (delivered through development).
  • Responsible for overall IT headcount.

Engineering Manager

Depending on the size of an organisation, an Engineering Manager may also be called a Chief Technical Officer (CTO) or Chief Information Officer (CIO) or Head of Software Development.

Although an Engineering Manager represents technology, they are often very far-removed from a development team and rarely code. In contrast, a Tech Lead sits with developers, very much focused on moving them towards their goal. They work to resolve technical disputes, and are watchful of technical decisions that have long-term consequences. A Tech Lead works closely with the Engineering Manager to build an ideal work environment.

A good Architect looks like a Tech Lead

The Architect role ensures overall application architecture suitably fits the business problem, for now and for the future. In some organisations, Architects work with the team to establish and validate their understanding of architecture. A suitable amount of standardisation helps productivity. Too much standardisation kills innovation.

Some organisations have the “Ivory Tower Architect” who swoops in to consult, standardise and document. They float from team-to-team, start new software projects, and rarely follow up to see the result of their initial architectural vision.

An effective Architect looks like a good Tech Lead. They establish a common understanding of what the team is aiming for, and make adjustments as the team learns more about the problem and the technology chosen to solve it.

What is a Tech Lead responsible for?

You may ask yourselves, what exactly does a Tech Lead do, or what are they accountable and responsible for? I’ve actually already addressed that in this article about the Tech Lead’s Circles of Responsibilities.

What is a Tech lead again?

A successful Tech Lead takes on responsibilities that sit with roles such as the Team Lead, the Architect and the Engineering Manager. They bring a unique blend of leadership and management skills applied in a technical context with a team of developers. The Tech Lead steers a team towards a common technical vision, writing code at least 30% of the time.

If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Update from Sep 2018: Short definition from “A Tech Lead is a developer who is responsible for leading a development team” to “A Tech Lead is a software engineer, responsible for leading a development team, and responsible for the quality of its technical deliverables.”

On Leadership and Being a Lead

Henry, the “Developer”

I once worked in a team with an amazing developer, let’s call him Henry (not his real name). Henry refused to play the Tech Lead, preferring to stay as hands-on with code as much as possible. When the team had a technical problem, they would first go to Henry. He always offered a well-balanced opinion on technical decisions which meant the team almost always agreed with his proposals. Even business people recognised his technical aptitude. When he asked for time to work on important technical tasks, he always got it.

Although Henry was just a “Developer”, he lead the team in a number of ways.

Taken from https://www.flickr.com/photos/growwear/4695020138 under the Creative Commons licence

Taken from https://www.flickr.com/photos/growwear/4695020138 under the Creative Commons licence

You don’t need to be a “Lead”

My experience with Henry showed me how you do not need a title with “Lead” to demonstrate leadership. Conversely, having a title with “Lead” doesn’t suddenly bestow someone with leadership skills.

A developer who cleans up some messy code without being asked demonstrates initiative. The tester who brings the developer and Product Manager to the same understanding demonstrates facilitation skills and these play a part of leading people. In this situation, it means:

Thinking and doing something for the benefit of the team without being told to do so.

There are, of course, many other attributes to being a leader, but that is a separate post.

A Lead without leadership

You have probably worked with one of these people. A leader who tells people what to do, berates their team members for stepping slightly out of their role, even when the result is beneficial for everyone. They often have the need to supervise the smallest task and always want a say in every decision. These people are nothing other than micromanagers and demonstrate no leadership skills whatsoever.

Great leaders encourage leadership

Unlike micromanagers, a real Lead focuses on creating an environment that allows everyone to demonstrate leadership. In chaotic situations, this may require more directive action with the goal of moving the team beyond a period of chaos into a safer environment. In a safer environment, the Lead encourages team members to do what they think is right. The Lead takes on a more guiding role and allows everyone to demonstrate leadership skills.

Action is not the same as a title

Henry the developer demonstrated that people can take on responsibilities without officially playing a certain role. He also reminded me that titles, certifications and labels do not automatically guarantee competence. If you truly want to lead, you can.

If you liked this article exploring leadership, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

The featured image is shared from Flickr under the Creative Commons licence.

Do we need a Tech Lead?

A common question I hear is, “Is the Tech Lead role necessary?” People argue against the role, claiming a team of well functioning developers can make decisions and prioritise what is important to work on. I completely agree with this position in an ideal world. Sadly the ideal world rarely exists.

Even when perfect conditions exist during which team members talk to each openly, discussing pros and cons before arriving at an agreed solution, it doesn’t take much to upset this delicate balance. Sometimes all it takes is for a new person joining the team, a person leaving or some stressful critical situation that drives the team into a state where arguing continues without end. My friend Roy Osherove calls this the “Chaos state.” I agree with him that a different style of leadership may be required, similar to the Situational Leadership Model.

Technical debates occur frequently in development teams. There is nothing worse than when the team reaches a frozen state of disagreement.

Tabs Spaces
Image take from Emacswiki

The Tech Lead has the responsibility to help the team move forwards. Sometimes that means using their authority. Sometimes it means working with the team to find a way forward. Facilitation and negotiation skills are invaluable assets to a Tech Lead. Understanding decision making models helps the Tech Lead decide when to step in, or when to step back. What is important is finding a way forward.

Tech Leads are also beneficial to people outside of the team, forming a single point of contact. Medium to large organisations start to hit communication barriers because there are too many relationships to effectively build and maintain. The Tech Lead role simplifies the communication path, although simultaneously adds a single point of failure. The balance between these two trade-offs should be carefully managed and monitored.

When played well, the Tech Lead provides countless other benefits, however the Tech Lead role does not have to played by a single person. I admire teams who say they don’t have a Tech Lead and software is still effectively delivered. They have successfully distributed the Tech Lead responsibilities or established processes to mitigate the need for the role. It does not necessarily mean the role itself is useless. The Tech Lead role is just that – just a role. Instead of focusing on whether or not the role should or should not exist, it is better to focus on ensuring all Tech Lead responsibilities are met.

If you liked this article exploring the Tech Lead role, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.

Disrupt yourself, or someone else will

A couple of days ago, Apple announced their new range of iPads including a mini with a retina display and a lighter, thinner full-sized iPad. Notice anything strange about their prices?

iPad2 Pricing

As can see the new mini retina priced at exactly the same price point as the (old) ipad2. Seem strange? You’re not the only one to think so as outlined by a comment from this appleinsider article.

Comment

This isn’t the first time Apple have priced a new product at the same as an older product (and probably won’t be the last).

The Innovator’s Dilemma
In the book, The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail, the author shows organisations that fail to embrace new technologies because they focus on the success of a single product or technology.

By offering these lines (new and old) Apple effectively segments their market into the early adopters of technology while providing (older and probably less appealing) options to all others. A conflict of features (retina display in a smaller form factor) makes users decide what is more important to them.

By removing the older iPad2, they effectively force consumers to move to the new platform and some of their customers may be happy with the existing product. Apple is effectively disrupting themself before their competition can.

Uses our cognitive biases

Having the same price point for a newer technology also taps into the anchoring cognitive bias (sometimes called the relativity trap).

Without the older product in the lineup, the newer products would not appear so appealing. The “anchor” of the older product is effectively pushing people to the newer products.

A person would ask:

Why would I buy older technology for the same price?

and then make the trade off for a smaller size, or if they want a newer size, pay another premium for it.

Book Review: Rethinking the Future

I recently finished the book, “Rethinking the Future” and I have to say how impressed I was by the book. The book is structured as a collection of essays from different well-known leaders and authors in different fields. I knew many, but not all, of the contributors and, as a result, the book offers a wide variety of perspectives. Some that complement, others that contrast with each author’s very opinionated view of the “future.” Bearing in mind this edition of the book was published in 1998, I find it interesting to see how still relevant many of the writings are today.

Rethinking the Future

Definitely focused as a business book, the contents are divided into different chapters trying to envisage the future from many different angles includes the way that businesses work, competition, control and complexity, leadership, markets and the world view. The book resonates very strongly with some of the works recently published such as truly understands what motivates people (i.e. Dan Pink’s Drive), or the need for management to balance even more and more states of paradox (e.g. Jim Highsmith’s Adaptive Leadership).

I don’t necessarily agree with all of the contributions in the book, particularly the idea of being focused on a single thing as described in the chapter, “Focused in a Fuzzy World.” I agree some focus is important, but I also believe in order to innovate, you sometimes have to unfocus. I see this as the problem often described by the Innovator’s Dilemma.

Book Review: The Human Side of Agile

A majority of books in the agile space always relate to the practices talked about in various methodologies, if not focusing on the methodologies themselves. With the Agile Manifesto talking about Individuals and interactions over Processes and Tools our community seemed to have missed a bit about how you go about building better interactions between individuals.

The Human Side of Agile

Fortunately a community member, Gil Broza wrote a book called The Human Side of Agile: How to Help Your Team Deliver. Gil was kind enough to send me a book a while back, but it was only on this trip to Agile Brazil that I managed to find the time read and reflect upon what I learned in the book.

My first impressions about the book is that it covers a solid range of topics. It addresses the role of leadership, strategies for getting to the ideal “self-empowered team” and useful advice on practical topics such as communication, meeting facilitation and about how to go about constantly improving. These are all topics that are often skipped, assumed easy, and are also the topics many people ask about at conferences. Fortunately Gil has been able to put a lot of practical advice, peppered with some great stories about what impact some of these ideas might have on the team.

The book is laid out in a series of questions, and so I can imagine people finding it particularly useful in a, “What do I do here?” situation. He covers topics some might avoid such as how to deal with behaviour seen as potentially destructive to the interactions of a team as well as dealing with the fact that people change in organisations and advice on how to deal with it.

This book provides a much needed guide to our industry where there was a big gap before. The writing is clear, easy to digest and quite approachable. Definitely one to add to any essential agile reading list.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑