Found an interesting blog post about Google’s study on team performance. It seems the most important thing is that team members feel secure enough to take risks without facing humiliation.
I find this interesting because it mirrors the recent book review I did in which Lencioni suggests a lack of trust is the first dysfunction of broken teams.
I’m fortunate to work in an industry that’s quite forward thinking. The abstract nature of our work means getting results is highly dependent on individuals working together. The team dynamic is built first and foremost on trust and respect. Without that no one’s going to pull an all nighter for you, nor will they back you up when you screw up.
For me, the easiest way to build this trust is to listen. Listening to my coworkers and allowing them to have their opinions heard helps build trust. At the very least they know I’ll hear them out if they have concerns. From there it’s a lot easier to get everyone engaged and trusting each other. It’s a small step in the right direction that can go a long way for productivity and team results.
Coming from the ASP .NET background the idea of a page life cycle is pretty well known to me. I was relieved to discover that React components follow a similar model: The Component Lifecycle. Briefly, these are defined methods that are always called during the life of a component and can be overridden with custom logic.
The similarities lie in the idea that there are specific events for the creation, use and termination of a Page or Component. Because ASP .NET is a server side rendered page it has a more complicated life cycle. If you want to compare take a look at this ASP .NET Page Life Cycle Overview.
The React Component is simplified and as such can be broken down into three phases:
- Creation and initial rendering – When a component is used it will need to be instantiated and rendered on the page. For this there are several methods which are executed in the following order:
- constructor(): If you’re familiar with object oriented programming this is the method that instantiates your component. Useful for setting up initial state of the component and binding your call backs.
- componentWillMount(): This is called immediately before mounting the component and rendering. This is useful because any logic in this method won’t trigger a re-render.
- render(): This is the real heart of a component where the actual output is specified (what will show up on the screen). This method is required. Also note that the render function should not modify state directly.
- componentDidMount(): Invoked immediately after the component is mounted. Any updates in this method will cause a re-render. This is a good location to fetch data from a remote source because the component will have rendered before the data is fetched.
- Using and updating the component – Once the component is mounted it will be interacted with. This is where the user gets a chance to use the component. The following methods are executed in order when the component is being re-rendered:
- componentWillReceiveProps(): This is called when the component props change (maybe being reset). This is not called during initial mounting and will only be called if some props update.
- shouldComponentUpdate(): React’s default behavior is to re-render on any state change. This method can be used to override that if there’s cases when an update shouldn’t cause the component to re-render.
- componentWillUpdate(): Similar to componentWillMount() this can be used for perparing before a re-render. Keep in mind that you can’t call this.setState() within this method.
- render(): Same as above. This is what outputs the component. All updates have been captured and pushed to the screen.
- componentDidUpdate(): Called immediately after the re-render. Similar to componentDidMount() and can be used for updating DOM elements or calling network resources.
- Disposing the component – At the end of the lifecycle the component is removed from the DOM. Here we have one useful method:
- componentWillUnmount(): This is called immediately before the component is unmounted and destroyed. Us this to clean up anything outstanding (network requests, DOM elements, timers etc.).
As you get into more complicated use cases your components will inevitably require the use of these lifecycle methods to handle complicated logic, data requirements and interactivity. Getting to know them will help in understanding React better.
The Five Dysfunctions of a Team: A Leadership Fable by Patrick Lencioni
I recently listened to this book in audiobook format as an exercise for better understanding team dynamics. I found this to be a decent book with some useful information.
The book is written as a fable which seems to be common in management literature. I like this format. The concepts are explained as they’re applied in a story that’s believable. I was able to relate to the characters and situations which helped me understand the five dysfunctions and their impacts.
The model is based on five interrelated dysfunctions which each contribute to each other and cumulatively lead to poor performance:
- Absence of Trust – Fear of being vulnerable with team members prevents the building of trust within the team. For a leader, showing vulnerability to the team helps build trust and makes being vulnerable acceptable within the team. This helps members accept each others weaknesses and built trust together.
- Fear of Conflict – The desire to preserver artificial harmony stifles the occurrence of productive ideological conflict. Directly tied to trust, if members can’t engage in conflict in a way they feel safe then decisions can’t be made. A leader must allow conflict to occur naturally and know when moderation is required.
- Lack of Commitment – The lack of clarity or buy-in prevents team members from making decisions they will stick to. If team members can’t voice their opinions for fear of conflict they won’t agree to a decision they don’t agree with. It’s important for a leader to allow everyone who shows any doubts to at least speak their mind in order to get buy in. Then once a decision is made all team members will accept the decision whether they agree with it or not. This commitment drives performance.
- Avoidance of Accountability – The need to avoid interpersonal discomfort prevents team members from holding one another accountable. If the team members aren’t committed they won’t feel a need to hold each other accountable. Without accountability nothing gets delivered. Normally a manager would dictate this to the team but a leader must enable each team member to hold each other accountable.
- Inattention to Results – The pursuit of individual goals and personal status erodes the focus on collective success. Perhaps the most difficult when each individual feels they are judged based on their individual performance. A leader must emphasize the importance of the team, as well as how each individual contributes to the team. If members buy into this and understand that their individual results should be framed in the context of team results the overall team performance can improve.
This has been quite interesting to me because organizational values can directly contribute to these dysfunctions. An organization that values individual performance is going to have a hard time getting the most out of team work. A company that doesn’t engage its employees in strategy and vision will never get full buy in and therefore employees just won’t be committed to strategic initiatives. In my industry there can be big egos and people afraid to fail. This leads to absence of trust and can be experienced from the top all the way down.
Overall I enjoyed this book. The model Lencioni has built seems to make sense to me and I agree with it for the most part. I was able to reflect on some of my own qualities and behaviors that make me a leader. There were also some good lessons that have inspired my next few subjects to explore.
Because this is a short read I’d recommend it to anyone interested in team dynamics and team management from human perspective.
The create-react-app boilerplate is pretty good. It’s easy to get up and running in react with this package. It also provides useful tools for compiling the application into a production ready deployment.
Unfortunately this doesn’t fit perfectly into the Azure pipeline because Microsoft wants to build things on the server. The Azure platform is great and they’ve got good support for Node.js apps. But with the create-react-app in particular a few steps need to be completed in order to get this up and running properly. There’s documentation for this out there but I ran into a couple small snags along the way.
- In my case I’m doing “npm install” then “npm run build” and finally using the kudu sync to copy the compiled app to the wwwroot folder.
- Connect your Azure web app to your repository. Microsoft provides support for a variety of source control repos for this. It’s fairly straightforward and well documented at here
- Properly set the node version: I had some problems where my node and npm versions were incorrect. The version can be set in the package.json file or the application settings. This blog post explains both.
- I needed to install the create-react-app and babel packages globally to handle proper transpiling. Log into Kudu from the Azure portal and run the npm install -g commands
If all goes well doing a commit and push to remote will kick off a build on the azure web app. From there the custom script will kick in and build the app using the create-react-app build script. Finally it should copy this to the wwwroot folder leaving you with a clean website.
The nice thing with the custom script is I’ll be able to get my unit tests running in there making it all automatic. The deploy will fail if the tests fail leaving the environment untouched. I’m excited to get this working for a very simple and streamlined CI pipeline.
Another useful post by Jeff Wilcox describing setting up custom builds on an Azure web app
As I’ve grown in my career and become more aware of future career paths I was always uncertain about the concept of leadership. In particular I’ve been wondering why I’m hearing leadership in place of management more and more. There are several reasons for this in my particular industry.
Leadership is a hot topic in all of business because effective leadership drives performance and results. A strong leader (at any level) can improve the performance of everyone in the team. Where leadership shines is during the difficult times in the workplace. A leader helps with difficult decisions, difficult conversations and difficult consequences.
I.T. as an industry has several qualities that make it unique. Change is constant and rapid. Many employees are well educated and highly intelligent. Most work is entirely abstract and difficult to grasp physically. On top of that there never really is a “right” solution for any problem. Decision making in this environment is difficult because of these factors and trying to get people to agree to decisions is even harder. Leadership demand is therefore emerging in I.T. where juggling the problems of technology with the human aspects of team management makes driving a team towards an effective solution challenging.
Contemporary software development practices also demand leadership. The Agile methodology and Scrum development practices advocate self organizing teams. No management positions are even listed for typical teams in these environments (Scrum Master and Product Owner being the closest). Regardless of title, leaders will emerge and must operate from a leadership role rather than a management role all while remaining equal to their peers. This is a difficult challenge. Organizations structured around Agile teams will have a different management layer that must provide guidance to these self organized teams. Here leadership is extremely important. Not only do these managers need to show leadership to numerous teams at the team level, they will often be engaged with every individual on each team. Helping to guide teams while providing individual leadership is probably not new but it seems like an interesting dynamic I haven’t been exposed to before.
Having experience in competitive sports in my youth brought out my interest in both teamwork and leadership. I’m now seeing it’s benefits in the workplace and I’d like to learn more about this in order to help myself, my colleagues, the teams I’m a part of and the employer I work for. There’s plenty of ideas and theories about leadership and I look forward to exploring this area and applying my own unique touch in my day to day life.
Continuous integration and Continuous deployment have once again changed for the better. Thanks to automation and Git hooks people are now doing deployments triggered directly off commits. This should drastically improve and speed up the overall CI and deployment paths.
I’m looking to implement this in Microsoft Azure which provides support for this
Continuous Deployment to Azure App Service
We are currently using a three environment configuration : CI, QA and Production with a staging slot meant for blue green deployments (ref: Martin Fowler).
So I’ve started working with React lately and it’s a significant change from some previous development paradigms. I’m enjoying learning something new that’s challenging and appears to be changing front end development. Here’s a few links I’ve found useful along the way:
Robin Wieruch blog